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.
This commit is contained in:
commit
37ba7a9825
|
@ -0,0 +1,8 @@
|
|||
*.pdf
|
||||
*.sw?
|
||||
*.bak
|
||||
*~
|
||||
*.html
|
||||
*__*.png
|
||||
*__*.svg
|
||||
generated/
|
|
@ -0,0 +1,26 @@
|
|||
all:
|
||||
cd OsmoBTS; $(MAKE)
|
||||
cd OsmoNITB; $(MAKE)
|
||||
cd OsmoBSC; $(MAKE)
|
||||
cd OsmoMGCP; $(MAKE)
|
||||
cd OsmoSGSN; $(MAKE)
|
||||
cd OsmoNAT; $(MAKE)
|
||||
cd OsmoPCU; $(MAKE)
|
||||
|
||||
clean:
|
||||
cd OsmoBTS; $(MAKE) clean
|
||||
cd OsmoNITB; $(MAKE) clean
|
||||
cd OsmoBSC; $(MAKE) clean
|
||||
cd OsmoMGCP; $(MAKE) clean
|
||||
cd OsmoSGSN; $(MAKE) clean
|
||||
cd OsmoNAT; $(MAKE) clean
|
||||
cd OsmoPCU; $(MAKE) clean
|
||||
|
||||
upload:
|
||||
cd OsmoBTS; $(MAKE) upload
|
||||
cd OsmoNITB; $(MAKE) upload
|
||||
cd OsmoBSC; $(MAKE) upload
|
||||
cd OsmoMGCP; $(MAKE) upload
|
||||
cd OsmoSGSN; $(MAKE) upload
|
||||
cd OsmoNAT; $(MAKE) upload
|
||||
cd OsmoPCU; $(MAKE) upload
|
|
@ -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)
|
|
@ -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
|
|
@ -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 <<bts>> and <<bts-examples>>.
|
||||
|
||||
==== 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 <<alink>>.
|
||||
|
||||
|
||||
==== 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 <<net>>, <<bts>> and <<bts-examples>>.
|
||||
|
||||
|
||||
==== 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.
|
|
@ -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 <<logging>> 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 <<logging>>
|
||||
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
|
||||
<<logging>> 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
|
||||
<<logging>> 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.
|
|
@ -0,0 +1,52 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1</revnumber>
|
||||
<date>February 2016</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Initial OsmoBSC manual, recycling OsmoNITB sections
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Holger</firstname>
|
||||
<surname>Freyther</surname>
|
||||
<email>hfreyther@sysmocom.de</email>
|
||||
<authorinitials>HF</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Harald</firstname>
|
||||
<surname>Welte</surname>
|
||||
<email>hwelte@sysmocom.de</email>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2012-2016</year>
|
||||
<holder>sysmocom - s.f.m.c. GmbH</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
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".
|
||||
</para>
|
||||
</legalnotice>
|
|
@ -0,0 +1,35 @@
|
|||
OsmoBSC User Manual
|
||||
===================
|
||||
Harald Welte <hwelte@sysmocom.de>
|
||||
|
||||
|
||||
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[]
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!--
|
||||
ex:ts=2:sw=42sts=2:et
|
||||
-*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
||||
-->
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
|
||||
"http://www.docbook.org/xml/5.0/dtd/docbook.dtd" [
|
||||
<!ENTITY chapter-vty SYSTEM "../common/chapters/vty.xml" >
|
||||
<!ENTITY sections-vty SYSTEM "generated/docbook_vty.xml" >
|
||||
]>
|
||||
|
||||
<book>
|
||||
<info>
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1</revnumber>
|
||||
<date>13th August 2012</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Initial</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v2</revnumber>
|
||||
<date>5th March 2014</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Update to match osmo-bsc version 0.13.0-305</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<title>OsmoBSC VTY Reference</title>
|
||||
|
||||
<copyright>
|
||||
<year>2012-2014</year>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>This work is copyright by <orgname>sysmocom - s.f.m.c. GmbH</orgname>. All rights reserved.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</info>
|
||||
|
||||
<!-- Main chapters-->
|
||||
&chapter-vty;
|
||||
</book>
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='25'>
|
||||
<child_of nodeid='4' />
|
||||
<name>MSC Connection Commands</name>
|
||||
<description>This node allows to configure the MSC connection related
|
||||
settings.</description>
|
||||
</node>
|
||||
<node id='30'>
|
||||
<child_of nodeid='4' />
|
||||
<name>BSC Commands</name>
|
||||
<description>This node allows to configure the BSC connection related
|
||||
settings.</description>
|
||||
</node>
|
||||
</vtydoc>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,14 @@
|
|||
TOPDIR := ..
|
||||
ASCIIDOCS := osmobts-usermanual osmobts-abis
|
||||
|
||||
include $(TOPDIR)/build/Makefile.asciidoc.inc
|
||||
|
||||
# for the upload target
|
||||
include $(TOPDIR)/build/Makefile.inc
|
||||
|
||||
# dependencies
|
||||
osmobts-abis.pdf: abis/*.adoc abis/*.msc
|
||||
osmobts-usermanual.pdf: chapters/*.adoc
|
||||
|
||||
clean:
|
||||
rm -rf $(cleanfiles)
|
|
@ -0,0 +1,23 @@
|
|||
msc {
|
||||
bts [label="BTS"], bsc [label="BSC"];
|
||||
|
||||
bts => bsc [label="TCP Connect (Port 3002, OML)"];
|
||||
bts box bsc [label="IPA CCM Identification (Port 3002)"];
|
||||
bts <= bsc [label="OML Configuration of BTS via OML"];
|
||||
...;
|
||||
bts <= bsc [label="OML (TRX=0) IPA RSL CONNECT"];
|
||||
bts => bsc [label="TCP Connect (Port 3003, RSL, TRX 0)"];
|
||||
bts box bsc [label="IPA CCM Identification Port 3003"];
|
||||
bts <= bsc [label="RSL BCCH filling (System Information)"];
|
||||
bts <= bsc [label="RSL SACCH filling (SI 5/6)"];
|
||||
...;
|
||||
bts <= bsc [label="OML (TRX=1) IPA RSL CONNECT"];
|
||||
bts => bsc [label="TCP Connect (Port 3003, RSL, TRX 1)"];
|
||||
bts box bsc [label="IPA CCM Identification (Port 3003)"];
|
||||
bts <= bsc [label="RSL SACCH filling (SI 5/6)"];
|
||||
...;
|
||||
bts <= bsc [label="OML (TRX=N) IPA RSL CONNECT"];
|
||||
bts => bsc [label="TCP Connect (Port 3003, RSL, TRX N)"];
|
||||
bts box bsc [label="IPA CCM Identification (Port 3003)"];
|
||||
bts <= bsc [label="RSL SACCH filling (SI 5/6)"];
|
||||
}
|
|
@ -0,0 +1,106 @@
|
|||
== IPA Multiplex
|
||||
|
||||
The ETSI/3GPP specifications for A-bis transport (ETSI/3GPP TS 08.56)
|
||||
specify the transmission of RSL and OML messages over a LAPD based
|
||||
framing on top of 64kBit/s signalling times slots (B-channels) on E1
|
||||
lines.
|
||||
|
||||
OsmoBTS does not implement this LAPD based transport, but instead
|
||||
implements A-bis over IP in a flavor first observed by ip.access nanoBTS
|
||||
products. The OsmoBTS implementation is a clean-room re-implementation
|
||||
based on the observation and dissection of protocol traces.
|
||||
|
||||
LAPD as used in E1 signalling channels provides in-order transmission
|
||||
and reliable delivery. This is why TCP was chosen as Layer 4 transport
|
||||
protocol on top of IP. TCP however, is a stream based transport
|
||||
protocol, which doesn't preserve the boundaries of messages.
|
||||
|
||||
To work around this shortcoming, an additional framing layer called the
|
||||
IPA multiplex was introduced between TCP and the RSL and OML messages.
|
||||
|
||||
.Protocol Stacking
|
||||
[width="30%"]
|
||||
|===
|
||||
|RSL + OML (this document)
|
||||
|IPA (this document)
|
||||
|TCP (IETF RFC 793)
|
||||
|IP (IETF RFC 791)
|
||||
|Ethernet (IEEE 802.3)
|
||||
|===
|
||||
|
||||
=== IPA Header
|
||||
|
||||
Each higher-layer PDU is encapsulated by a three-byte IPA header with
|
||||
the following structure:
|
||||
|
||||
.IPA Header Structure
|
||||
[options="header",cols="10%,15%,15%,60%"]
|
||||
|===
|
||||
|Offset (Octets)|Length|Name|Description
|
||||
|0|2|Length|Length of the variable-length payload section in network
|
||||
byte order (excluding the length of the IPA Header)
|
||||
|2|1|Stream Identifier|Identifies the stream of the payload
|
||||
|3|Variable|Payload|higher-layer PDU (i.e. RSL or OML message)
|
||||
|===
|
||||
|
||||
=== IPA Stream Identifiers
|
||||
|
||||
The IPA Stream Identifier serves to differentiate different streams
|
||||
within the multiplex. In the context of A-bis, it can be seen as
|
||||
analogous to the LAPD TEI on classic A-bis over E1.
|
||||
|
||||
The following IPA stream identifiers are being used in A-bis/IP:
|
||||
|
||||
.IPA Stream Identifiers
|
||||
[options="header",width="70%",cols="20%,20%,60%"]
|
||||
|===
|
||||
|Value (Hex)|Name|Description
|
||||
|0x00|RSL|A-bis RSL according to this document, TRX 0
|
||||
|0x01|RSL|A-bis RSL according to this document, TRX 1
|
||||
|0x0n|RSL|A-bis RSL according to this document, TRX n
|
||||
|0xfe|CCM|IPA Connection Management
|
||||
|0xff|OML|A-bis OML according to this document
|
||||
|===
|
||||
|
||||
|
||||
=== IPA Connection Management (CCM)
|
||||
|
||||
The IPA Connection Management is a sub-layer underneath the IPA
|
||||
multiplex which is used to manage the connection itself. It supports
|
||||
functions like Identity Management and Keep-Alive.
|
||||
|
||||
==== Identity Management
|
||||
|
||||
When a BTS connects to the BSC, the BSC must identify the connected BTS
|
||||
somehow. In ETSI/3GPP A-bis, the E1 multiplex + signalling timeslot
|
||||
number is used for this. In IP, there is no similar usable identity.
|
||||
Hence, the Unit ID is used for this purpose.
|
||||
|
||||
.Procedure for IPA peer identification is as follows
|
||||
[options="header",cols="20%,80%"]
|
||||
|===
|
||||
|Direction|Operation
|
||||
|BTS -> BSC|BTS connects the TCP connection to be used with IPA
|
||||
|BTS <- BSC|BSC requests BTS identity with ID_GET
|
||||
|BTS -> BSC|BTS responds BTS Unit ID with ID_RESP
|
||||
|BTS <- BSC|BSC responds with ID_ACK, if the Unit ID is known to the BSC
|
||||
|===
|
||||
|
||||
Following the above peer identification procedure, transfer of
|
||||
higher-level messages such as OML or RSL commences.
|
||||
|
||||
==== IPA CCM Messages
|
||||
|
||||
IPA CCM supports the following messages
|
||||
|
||||
.IPA CCM Messages
|
||||
[options="header"]
|
||||
[cols="10%,15%,75%"]
|
||||
|===
|
||||
|Value|Name|Purpose
|
||||
|0x00|PING|Request a PONG from the peer
|
||||
|0x01|PONG|Response to a PING
|
||||
|0x04|ID_GET|Request Identity from peer
|
||||
|0x05|ID_RESP|Response to ID_GET
|
||||
|0x06|ID_ACK|Identity Acknowledged
|
||||
|===
|
|
@ -0,0 +1,26 @@
|
|||
msc {
|
||||
bts [label="BTS"], bsc [label="BSC"];
|
||||
# this is for the BTS Object
|
||||
--- [label="Initial state after establishing OML"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Notinstalled/Locked)"];
|
||||
--- [label="MO requests software activation"];
|
||||
bts => bsc [label="SW Activate Req"];
|
||||
bts <= bsc [label="SW Activate Req Ack"];
|
||||
--- [label="BTS instructs BTS to activate software"];
|
||||
bts <= bsc [label="Activate SW"];
|
||||
bts => bsc [label="Activate SW Ack"];
|
||||
--- [label="MO reports new state after SW activation"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Dependency)"];
|
||||
bts => bsc [label="SW Activated Report"];
|
||||
--- [label="Configure the MO with its attributes"];
|
||||
bts <= bsc [label="Set BTS Attributes"];
|
||||
bts => bsc [label="Set BTS Attributes Ack"];
|
||||
bts <= bsc [label="OPSTART"];
|
||||
bts => bsc [label="OPSTART ACK"];
|
||||
--- [label="As this object is locked, we need to unlock it"];
|
||||
bts <= bsc [label="Change Adm State (Unlocked)"];
|
||||
bts => bsc [label="Change Adm State Ack (Unlocked)"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Dependency/Unlocked)"];
|
||||
--- [label="Initialize Radio Transceiver, Radio Carrier, Channels"];
|
||||
bts => bsc [label="STATE CHG REP (Enabled/OK)"];
|
||||
}
|
|
@ -0,0 +1,24 @@
|
|||
msc {
|
||||
bts [label="Radio Carrier"], bsc [label="BSC"];
|
||||
--- [label="Initial state after establishing OML"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Notinstalled/Locked)"];
|
||||
--- [label="MO requests software activation"];
|
||||
bts => bsc [label="SW Activate Req"];
|
||||
bts <= bsc [label="SW Activate Req Ack"];
|
||||
--- [label="BTS instructs BTS to activate software"];
|
||||
bts <= bsc [label="Activate SW"];
|
||||
bts => bsc [label="Activate SW Ack"];
|
||||
--- [label="MO reports new state after SW activation"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Offline)"];
|
||||
bts => bsc [label="SW Activated Report"];
|
||||
--- [label="Configure the MO with its attributes"];
|
||||
bts <= bsc [label="Set Radio Carrier Attributes"];
|
||||
bts => bsc [label="Set Radio Carrier Attributes Ack"];
|
||||
bts <= bsc [label="OPSTART"];
|
||||
bts => bsc [label="OPSTART ACK"];
|
||||
--- [label="As this object is locked, we need to unlock it"];
|
||||
bts <= bsc [label="Change Adm State (Unlocked)"];
|
||||
bts => bsc [label="Change Adm State Ack (Unlocked)"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/OK/Unlocked)"];
|
||||
bts => bsc [label="STATE CHG REP (Enabled)"];
|
||||
}
|
|
@ -0,0 +1,20 @@
|
|||
msc {
|
||||
bts [label="Channel"], bsc [label="BSC"];
|
||||
--- [label="Initial state after establishing OML"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Notinstalled/Locked)"];
|
||||
--- [label="MO reports new state after SW activation of Baseband Transceiver"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Dependency)"];
|
||||
bts => bsc [label="SW Activated Report"];
|
||||
--- [label="Configure the MO with its attributes"];
|
||||
bts <= bsc [label="Set Channel Attributes"];
|
||||
bts => bsc [label="Set Channel Attributes Ack"];
|
||||
bts <= bsc [label="OPSTART"];
|
||||
bts => bsc [label="OPSTART ACK"];
|
||||
--- [label="As this object is locked, we need to unlock it"];
|
||||
bts <= bsc [label="Change Adm State (Unlocked)"];
|
||||
bts => bsc [label="Change Adm State Ack (Unlocked)"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Dependency/Unlocked)"];
|
||||
--- [label="Initialize Radio Carrier / Baseband Transceiver"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Offline)"];
|
||||
bts => bsc [label="STATE CHG REP (Enabled/OK)"];
|
||||
}
|
|
@ -0,0 +1,17 @@
|
|||
msc {
|
||||
bts [label="Site Manager"], bsc [label="BSC"];
|
||||
# this is for the Site Manager Object
|
||||
--- [label="Initial state after establishing OML"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Notinstalled)"];
|
||||
--- [label="MO requests software activation"];
|
||||
bts => bsc [label="SW Activate Req"];
|
||||
bts <= bsc [label="SW Activate Req Ack"];
|
||||
--- [label="BTS instructs BTS to activate software"];
|
||||
bts <= bsc [label="Activate SW"];
|
||||
bts => bsc [label="Activate SW Ack"];
|
||||
--- [label="MO reports new state after SW activation"];
|
||||
bts => bsc [label="STATE CHG REP (Enabled)"];
|
||||
bts => bsc [label="SW Activated Report"];
|
||||
bts <= bsc [label="OPSTART"];
|
||||
bts => bsc [label="OPSTART ACK"];
|
||||
}
|
|
@ -0,0 +1,23 @@
|
|||
msc {
|
||||
bts [label="Baseband Transceiver"], bsc [label="BSC"];
|
||||
--- [label="Initial state after establishing OML"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Notinstalled/Locked)"];
|
||||
--- [label="MO requests software activation"];
|
||||
bts => bsc [label="SW Activate Req"];
|
||||
bts <= bsc [label="SW Activate Req Ack"];
|
||||
--- [label="BTS instructs BTS to activate software"];
|
||||
bts <= bsc [label="Activate SW"];
|
||||
bts => bsc [label="Activate SW Ack"];
|
||||
--- [label="MO reports new state after SW activation"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Dependency)"];
|
||||
bts => bsc [label="SW Activated Report"];
|
||||
--- [label="BSC requests RSL establishment"];
|
||||
bts <= bsc [label="IPA RSL Connect"];
|
||||
bts => bsc [label="IPA RSL Connect ACK"];
|
||||
bts <= bsc [label="OPSTART"];
|
||||
bts => bsc [label="OPSTART ACK"];
|
||||
--- [label="As this object is locked, we need to unlock it"];
|
||||
bts <= bsc [label="Change Adm State (Unlocked)"];
|
||||
bts => bsc [label="Change Adm State Ack (Unlocked)"];
|
||||
bts => bsc [label="STATE CHG REP (Disabled/Dependency/Unlocked)"];
|
||||
}
|
|
@ -0,0 +1,34 @@
|
|||
msc {
|
||||
hscale = 2;
|
||||
|
||||
chan [label="Channel"], rc [label="Radio Carrier"], smg [label="Site Manager"], bts [label="BTS"], bsc [label="BSC"];
|
||||
|
||||
bts => bsc [label="TCP Connect (Port 3003, OML)"];
|
||||
bts box bsc [label="IPA CCM Identification (Port 3003)"];
|
||||
|||;
|
||||
smg => bsc [label="(Site Mgr) STATE CHG REP (Disabled/NotInstalled)"];
|
||||
bts => bsc [label="(BTS) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
rc => bsc [label="(TRANSC) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 0) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 1) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 2) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 3) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 4) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 5) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 6) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
chan => bsc [label="(Ch 7) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
rc => bsc [label="(RC) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
bts => bsc [label="(GPRS-NSE) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
bts => bsc [label="(GPRS-CELL) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
bts => bsc [label="(GPRS-NSVC0) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
bts => bsc [label="(GPRS-NSVC1) STATE CHG REP (Disabled/NotInstalled/Locked)"];
|
||||
|||;
|
||||
smg => bsc [label="(Site Mgr) SW Activate Req"];
|
||||
smg <= bsc [label="(Site Mgr) SW Activate Req Ack"];
|
||||
smg <= bsc [label="(Site Mgr) Activate SW"];
|
||||
smg => bsc [label="(Site Mgr) Activate SW Ack"];
|
||||
smg => bsc [label="(Site Mgr) STATE CHG REP (Enabled)"];
|
||||
smg => bsc [label="(Site Mgr) SW Activated Report"];
|
||||
smg <= bsc [label="(Site Mgr) OPSTART"];
|
||||
smg => bsc [label="(Site Mgr) OPSTART ACK"];
|
||||
}
|
|
@ -0,0 +1,50 @@
|
|||
msc {
|
||||
hscale = 2;
|
||||
|
||||
chan [label="Channel"], rc [label="Radio Carrier"], bts [label="BTS"], bsc [label="BSC"];
|
||||
|
||||
bts box bsc [label="OML Connect + Site Manager Init"];
|
||||
...;
|
||||
bts => bsc [label="(BTS) SW Activate Req"];
|
||||
bts <= bsc [label="(BTS) SW Activate Req Ack"];
|
||||
bts <= bsc [label="(BTS) Activate SW"];
|
||||
bts => bsc [label="(BTS) Activate SW Ack"];
|
||||
bts => bsc [label="(BTS) STATE CHG REP (Disabled/Dependency)"];
|
||||
bts => bsc [label="(BTS) SW Activated Report"];
|
||||
|||;
|
||||
rc => bsc [label="(TRANSC) SW Activate Req"];
|
||||
rc => bsc [label="(RC) SW Activated Req"];
|
||||
|||;
|
||||
bts <= bsc [label="(BTS) Set BTS Attributes"];
|
||||
bts => bsc [label="(BTS) Set BTS Attributes Ack"];
|
||||
bts <= bsc [label="(BTS) OPSTART"];
|
||||
bts => bsc [label="(BTS) OPSTART Ack"];
|
||||
|||;
|
||||
bts <= bsc [label="(BTS) Change Adm State (Unlocked)"];
|
||||
bts => bsc [label="(BTS) Change Adm State ACK (Unlocked)"];
|
||||
bts => bsc [label="(BTS) STATE CHG REP (Disabled/Dependency/Unlcoked)"];
|
||||
|||;
|
||||
rc <= bsc [label="(TRANSC) SW Activate Req Ack"];
|
||||
rc <= bsc [label="(TRANSC) Activate SW"];
|
||||
rc => bsc [label="(TRANSC) Activate SW Ack"];
|
||||
rc => bsc [label="(TRANSC) STATE CHG REP (Disabled/Dependency)"];
|
||||
rc => bsc [label="(TRANSC) SW Activated Report"];
|
||||
|
||||
chan => bsc [label="(CHAN 0) STATE CHG REP (Disabled/Dependency)"];
|
||||
chan => bsc [label="(CHAN 1) STATE CHG REP (Disabled/Dependency)"];
|
||||
chan => bsc [label="(CHAN 2) STATE CHG REP (Disabled/Dependency)"];
|
||||
chan => bsc [label="(CHAN 3) STATE CHG REP (Disabled/Dependency)"];
|
||||
chan => bsc [label="(CHAN 4) STATE CHG REP (Disabled/Dependency)"];
|
||||
chan => bsc [label="(CHAN 5) STATE CHG REP (Disabled/Dependency)"];
|
||||
chan => bsc [label="(CHAN 6) STATE CHG REP (Disabled/Dependency)"];
|
||||
chan => bsc [label="(CHAN 7) STATE CHG REP (Disabled/Dependency)"];
|
||||
|||;
|
||||
chan => bsc [label="(CHAN 0) SW Activated Report"];
|
||||
chan => bsc [label="(CHAN 1) SW Activated Report"];
|
||||
chan => bsc [label="(CHAN 2) SW Activated Report"];
|
||||
chan => bsc [label="(CHAN 3) SW Activated Report"];
|
||||
chan => bsc [label="(CHAN 4) SW Activated Report"];
|
||||
chan => bsc [label="(CHAN 5) SW Activated Report"];
|
||||
chan => bsc [label="(CHAN 6) SW Activated Report"];
|
||||
chan => bsc [label="(CHAN 7) SW Activated Report"];
|
||||
}
|
|
@ -0,0 +1,51 @@
|
|||
msc {
|
||||
hscale = 2;
|
||||
|
||||
chan [label="Channel"], rc [label="Radio Carrier"], bts [label="BTS"], bsc [label="BSC"];
|
||||
|
||||
...;
|
||||
rc <= bsc [label="(RC) SW Activate Req Ack"];
|
||||
rc <= bsc [label="(RC) Activate SW"];
|
||||
rc => bsc [label="(RC) Activate SW Ack"];
|
||||
rc => bsc [label="(RC) STATE CHG REP (Disabled/Offline)"];
|
||||
rc => bsc [label="(RC) SW Activated Report"];
|
||||
rc <= bsc [label="(TRANSC) IPA RSL Connect"];
|
||||
rc => bsc [label="(TRANSC) IPA RSL Connect Ack"];
|
||||
rc <= bsc [label="(TRANSC) OPSTART"];
|
||||
rc => bsc [label="(TRANSC) OPSTART Ack"];
|
||||
rc <= bsc [label="(TRANSC) Change Adm State (Unlocked)"];
|
||||
rc => bsc [label="(TRANSC) Change Adm State Ack (Unlocked)"];
|
||||
rc => bsc [label="(TRANSC) STATE CHG REP (Disabled/Dependency/Unlocked)"];
|
||||
|||;
|
||||
chan <= bsc [label="(CHAN 0) Set Channel Attributes"];
|
||||
chan => bsc [label="(CHAN 0) Set Channel Attributes Ack"];
|
||||
chan <= bsc [label="(CHAN 0) OPSTART"];
|
||||
chan => bsc [label="(CHAN 0) OPSTART Ack"];
|
||||
chan <= bsc [label="(CHAN 0) Change Adm State (Unlocked)"];
|
||||
chan => bsc [label="(CHAN 0) Change Adm State Ack (Unlocked)"];
|
||||
chan => bsc [label="(CHAN 0) STATE CHG REP (Disabled/Dependency/Unlocked)"];
|
||||
...;
|
||||
chan <= bsc [label="(CHAN 7) Set Channel Attributes"];
|
||||
chan => bsc [label="(CHAN 7) Set Channel Attributes Ack"];
|
||||
chan <= bsc [label="(CHAN 7) OPSTART"];
|
||||
chan => bsc [label="(CHAN 7) OPSTART Ack"];
|
||||
chan <= bsc [label="(CHAN 7) Change Adm State (Unlocked)"];
|
||||
chan => bsc [label="(CHAN 7) Change Adm State Ack (Unlocked)"];
|
||||
chan => bsc [label="(CHAN 7) STATE CHG REP (Disabled/Dependency/Unlocked)"];
|
||||
|||;
|
||||
rc <= bsc [label="(RC) Set Radio Carrier Attributes"];
|
||||
rc => bsc [label="(RC) Set Radio Carrier Attributes Ack"];
|
||||
rc <= bsc [label="(RC) OPSTART"];
|
||||
rc => bsc [label="(RC) OPSTART Ack"];
|
||||
rc <= bsc [label="(RC) Change Adm State (Unlocked)"];
|
||||
rc => bsc [label="(RC) Change Adm State Ack (Unlocked)"];
|
||||
rc => bsc [label="(RC) STATE CHG REP (Disabled/OK/Unlocked)"];
|
||||
rc => bsc [label="(RC) STATE CHG REP (Enabled)"];
|
||||
rc => bsc [label="(TRANSC) STATE CHG REP (Disabled/Offline)"];
|
||||
rc => bsc [label="(TRANSC) STATE CHG REP (Enabled/OK)"];
|
||||
|||;
|
||||
chan => bsc [label="(CHAN 0) STATE CHG REP (Disabled/Offline)"];
|
||||
chan => bsc [label="(CHAN 0) STATE CHG REP (Enabled/OK)"];
|
||||
|||;
|
||||
bts => bsc [label="(BTS) STATE CHG REP (Enabled/OK)"];
|
||||
}
|
|
@ -0,0 +1,937 @@
|
|||
== Organization & Maintenance Link (OML)
|
||||
|
||||
=== List of Messages
|
||||
|
||||
The following tables list the OML messages used by OsmoBTS, grouped by their
|
||||
level of compliance with 3GPP TS 12.21.
|
||||
|
||||
==== Messages Compliant With TS 12.21
|
||||
|
||||
Specific limitations apply, see the linked sections.
|
||||
|
||||
.Messages compliant with TS 12.21
|
||||
[options="header",cols="10%,10%,20%,35%,5%,20%"]
|
||||
|===
|
||||
| TS 12.21 § | type code (hex) | This document § | Message | <-/-> | Received/Sent by OsmoBTS
|
||||
6+<| *SW Download Management Messages:*
|
||||
| 8.3.7 | 0x10 | <<sw_act_rep>> | SW Activated Report | -> | Sent
|
||||
6+<| *Air Interface Management Messages:*
|
||||
.3+.| 8.6.1 | 0x41 .3+.| <<set_bts_attr>> | Set BTS Attributes | <- | Received
|
||||
| 0x42 | Set BTS Attributes Ack | -> | Sent
|
||||
| 0x43 | Set BTS Attributes Nack | -> | Sent
|
||||
.3+.| 8.6.2 | 0x44 .3+.| <<set_radio_attr>> | Set Radio Carrier Attributes | <- | Received
|
||||
| 0x45 | Set Radio Carrier Attributes Ack | -> | Sent
|
||||
| 0x46 | Set Radio Carrier Attributes Nack | -> | Sent
|
||||
.3+.| 8.6.3 | 0x47 .3+.| <<set_chan_attr>> | Set Channel Attributes | <- | Received
|
||||
| 0x48 | Set Channel Attributes Ack | -> | Sent
|
||||
| 0x49 | Set Channel Attributes Nack | -> | Sent
|
||||
6+<| *State Management and Event Report Messages:*
|
||||
| 8.8.1 | 0x61 | <<state_changed_rep>> | State Changed Event Report | -> | Sent
|
||||
.3+.| 8.8.5 | 0x69 .3+.| <<chg_adm_state>> | Change Administrative State | <- | Received
|
||||
| 0x6A | Change Administrative State Ack | -> | Sent
|
||||
| 0x6B | Change Administrative State Nack | -> | Sent
|
||||
6+<| *Equipment Management Messages:*
|
||||
.3+.| 8.9.2 | 0x74 .3+.| <<opstart>> | Opstart | <- | Received
|
||||
| 0x75 | Opstart Ack | -> | Sent
|
||||
| 0x76 | Opstart Nack | -> | Sent
|
||||
|===
|
||||
|
||||
|
||||
==== Messages Specific to OsmoBTS
|
||||
|
||||
.Messages specific to OsmoBTS, not found in 3GPP TS 12.21
|
||||
[options="header"]
|
||||
[options="header",cols="20%,55%,5%,20%"]
|
||||
|===
|
||||
| This document § | Message | <-/-> | Received/Sent by OsmoBTS
|
||||
| <<ipacc_set_attr>> | Set Attribute | <- | Received
|
||||
|===
|
||||
|
||||
|
||||
==== Messages Not Implemented by OsmoBTS
|
||||
.3GPP TS 12.21 messages not implemented by OsmoBTS
|
||||
[options="header",cols="10%,10%,80%"]
|
||||
|===
|
||||
| TS 12.21 § | type code (hex) | Message
|
||||
3+<| *SW Download Management Messages:*
|
||||
.3+.| 8.3.1 | 0x01 | Load Data Initiate
|
||||
| 0x02 | Load Data Initiate Ack
|
||||
| 0x03 | Load Data Initiate Nack
|
||||
.2+.| 8.3.2 | 0x04 | Load Data Segment
|
||||
| 0x05 | Load Data Segment Ack
|
||||
| 8.3.3 | 0x06 | Load Data Abort
|
||||
.3+.| 8.3.4 | 0x07 | Load Data End
|
||||
| 0x08 | Load Data End Ack
|
||||
| 0x09 | Load Data End Nack
|
||||
.3+.| 8.3.5 | 0x0A | SW Activate Request
|
||||
| 0x0B | SW Activate Request Ack
|
||||
| 0x0C | SW Activate Request Nack
|
||||
.3+.| 8.3.6 | 0x0D | Activate SW
|
||||
| 0x0E | Activate SW Ack
|
||||
| 0x0F | Activate SW Nack
|
||||
3+<| *A-bis Interface Management Messages:*
|
||||
.3+.| 8.4.1 | 0x21 | Establish TEI
|
||||
| 0x22 | Establish TEI Ack
|
||||
| 0x23 | Establish TEI Nack
|
||||
.3+.| 8.4.2 | 0x24 | Connect Terrestrial Signalling
|
||||
| 0x25 | Connect Terrestrial Signalling Ack
|
||||
| 0x26 | Connect Terrestrial Signalling Nack
|
||||
.3+.| 8.4.3 | 0x27 | Disconnect Terrestrial Signalling
|
||||
| 0x28 | Disconnect Terrestrial Signalling Ack
|
||||
| 0x29 | Disconnect Terrestrial Signalling Nack
|
||||
.3+.| 8.4.4 | 0x2A | Connect Terrestrial Traffic
|
||||
| 0x2B | Connect Terrestrial Traffic Ack
|
||||
| 0x2C | Connect Terrestrial Traffic Nack
|
||||
.3+.| 8.4.5 | 0x2D | Disconnect Terrestrial Traffic
|
||||
| 0x2E | Disconnect Terrestrial Traffic Ack
|
||||
| 0x2F | Disconnect Terrestrial Traffic Nack
|
||||
3+<| *Transmission Management Messages:*
|
||||
.3+.| 8.5.1 | 0x31 | Connect Multi-Drop Link
|
||||
| 0x32 | Connect Multi-Drop Link Ack
|
||||
| 0x33 | Connect Multi-Drop Link Nack
|
||||
.3+.| 8.5.2 | 0x34 | Disconnect Multi-Drop Link
|
||||
| 0x35 | Disconnect Multi-Drop Link Ack
|
||||
| 0x36 | Disconnect Multi-Drop Link Nack
|
||||
3+<| *Test Management Messages:*
|
||||
.3+.| 8.7.1 | 0x51 | Perform Test
|
||||
| 0x52 | Perform Test Ack
|
||||
| 0x53 | Perform Test Nack
|
||||
.3+.| 8.7.2 | 0x54 | Test Report
|
||||
| 0x55 | Send Test Report
|
||||
| 0x56 | Send Test Report Ack
|
||||
| 8.7.3 | 0x57 | Send Test Report Nack
|
||||
.3+.| 8.7.4 | 0x58 | Stop Test
|
||||
| 0x59 | Stop Test Ack
|
||||
| 0x5A | Stop Test Nack
|
||||
3+<| *State Management and Event Report Messages:*
|
||||
| 8.8.2 | 0x62 | Failure Event Report
|
||||
.3+.| 8.8.3 | 0x63 | Stop Sending Event Reports
|
||||
| 0x64 | Stop Sending Event Reports Ack
|
||||
| 0x65 | Stop Sending Event Reports Nack
|
||||
.3+.| 8.8.4 | 0x66 | Restart Sending Event Reports
|
||||
| 0x67 | Restart Sending Event Reports Ack
|
||||
| 0x68 | Restart Sending Event Reports Nack
|
||||
.3+.| 8.8.6 | 0x6C | Change Administrative State Request
|
||||
| 0x6D | Change Administrative State Request Ack
|
||||
| 0x6E | Change Administrative State Request Nack
|
||||
.3+.| 8.8.7 | 0x93 | Report Outstanding Alarms
|
||||
| 0x94 | Report Outstanding Alarms Ack
|
||||
| 0x95 | Report Outstanding Alarms Nack
|
||||
3+<| *Equipment Management Messages:*
|
||||
.3+.| 8.9.1 | 0x71 | Changeover
|
||||
| 0x72 | Changeover Ack
|
||||
| 0x73 | Changeover Nack
|
||||
.3+.| 8.9.3 | 0x87 | Reinitialize
|
||||
| 0x88 | Reinitialize Ack
|
||||
| 0x89 | Reinitialize Nack
|
||||
.3+.| 8.9.4 | 0x77 | Set Site Outputs
|
||||
| 0x78 | Set Site Outputs Ack
|
||||
| 0x79 | Set Site Outputs Nack
|
||||
.3+.| 8.9.5 | 0x90 | Change HW Configuration
|
||||
| 0x91 | Change HW Configuration Ack
|
||||
| 0x92 | Change HW Configuration Nack
|
||||
3+<| *Measurement Management Messages:*
|
||||
| 8.10.1 | 0x8A | Measurement Result Request
|
||||
| 8.10.2 | 0x8B | Measurement Result Response
|
||||
| 8.10.3 | 0x8C | Stop Measurement
|
||||
| 8.10.4 | 0x8D | Start Measurement
|
||||
3+<| *Other Messages:*
|
||||
| 8.11.1 | 0x81 | Get Attributes
|
||||
| 8.11.3 | 0x82 | Get Attribute(s) Response
|
||||
| 8.11.1 | 0x83 | Get Attributes Nack
|
||||
.3+.| 8.11.2 | 0x84 | Set Alarm Threshold
|
||||
| 0x85 | Set Alarm Threshold Ack
|
||||
| 0x86 | Set Alarm Threshold Nack
|
||||
|===
|
||||
|
||||
|
||||
=== Details on Compliant OML Messages
|
||||
|
||||
[[sw_act_rep]]
|
||||
==== SW Activated Report
|
||||
|
||||
OsmoBTS will send an _SW Activated Report_ when RF has been activated
|
||||
successfully. The message is compliant with 3GPP TS 12.21 § 8.3.7.
|
||||
|
||||
Upon RF activation, two _SW Activated Report_ messages will be sent, for the Object Classes
|
||||
|
||||
- Radio Carrier (0x02)
|
||||
- Baseband Transceiver (0x04)
|
||||
|
||||
[[set_bts_attr]]
|
||||
==== Set BTS Attributes
|
||||
|
||||
OsmoBTS will receive a _Set BTS Attributes_ message and reply with a
|
||||
corresponding ACK message on success. IE handling is fully compliant to TS
|
||||
12.21, except that a change of BCCH ARFCN or BSIC while in operation is not
|
||||
supported, and hence the _Starting Time_ IE is rejected.
|
||||
|
||||
._Set BTS Attributes_ IEs not handled by OsmoBTS
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 12.21 § | IE Name | Handling
|
||||
| 9.4.52 | Starting Time | not supported (provokes NACK cause 0x10)
|
||||
|===
|
||||
|
||||
|
||||
[[set_radio_attr]]
|
||||
==== Set Radio Carrier Attributes
|
||||
|
||||
This message conforms to 3GPP TS 12.21, with the following limitation,
|
||||
as frequency hopping is not supported by OsmoBTS:
|
||||
|
||||
._Set Radio Carrier Attributes_ IE limitations
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 12.21 § | IE Name | Handling
|
||||
| 9.4.5 | ARFCN List | ignored
|
||||
|===
|
||||
|
||||
|
||||
[[set_chan_attr]]
|
||||
==== Set Channel Attributes
|
||||
|
||||
This message conforms to 3GPP TS 12.21, with the following limitation: OpenBTS
|
||||
does not support frequency hopping, and the following 3GPP TS 12.21 IEs provoke
|
||||
a NACK response when sent to OsmoBTS, as frequency hopping is not
|
||||
supported:
|
||||
|
||||
._Set Channel Attributes_ IE limitations
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 12.21 § | IE Name | Handling
|
||||
| 9.4.21 | HSN | not supported (provokes NACK cause 0x10)
|
||||
| 9.4.27 | MAIO | not supported (provokes NACK cause 0x10)
|
||||
| 9.4.52 | Starting Time | not supported (provokes NACK cause 0x10)
|
||||
|===
|
||||
|
||||
[[state_changed_rep]]
|
||||
==== State Changed Event Report
|
||||
|
||||
This message is compliant with 3GPP TS 12.21. Exactly these IEs are sent by
|
||||
OsmoBTS:
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message Type (0xf5) | 3GPP TS 12.21 9.1 | M | V | 1
|
||||
| Object Class | 3GPP TS 12.21 9.2 | M | V | 1
|
||||
| Object Instance | 3GPP TS 12.21 9.3 | M | V | 3
|
||||
| Operational State | 3GPP TS 12.21 9.4.38 | O | TV | 2
|
||||
| Availability Status | 3GPP TS 12.21 9.4.7 | O | TL16V (with length of 1) | 3
|
||||
|===
|
||||
|
||||
[[chg_adm_state]]
|
||||
==== Change Administrative State
|
||||
|
||||
This message is compliant with 3GPP TS 12.21 § 8.8.5. It applies to all of the
|
||||
Objects Classes defined in 3GPP TS 12.21 § 9.2 as well as
|
||||
<<addnl_obj_classes>>.
|
||||
|
||||
[[opstart]]
|
||||
==== Opstart
|
||||
|
||||
This message is compliant with 3GPP TS 12.21 § 8.9.2. It applies to all of the
|
||||
Objects Classes defined in 3GPP TS 12.21 § 9.2 as well as
|
||||
<<addnl_obj_classes>>.
|
||||
|
||||
|
||||
=== Details on OsmoBTS Specific Messages
|
||||
|
||||
[[ipacc_set_attr]]
|
||||
==== Set Attribute
|
||||
|
||||
The message type is 0xf5. This message is sent to OsmoBTS to set
|
||||
attributes on instances of managed objects of the non-standard
|
||||
additional Object Classes (see <<addnl_obj_classes>>).
|
||||
|
||||
The message specifics depend on the Object Class and are detailed in
|
||||
<<addnl_obj_classes>>.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message Type (0xf5) | 3GPP TS 12.21 9.1 | M | V | 1
|
||||
| Object Class | 3GPP TS 12.21 9.2 | M | V | 1
|
||||
| Object Instance | 3GPP TS 12.21 9.3 | M | V | 3
|
||||
5+<| _Object Class specific IEs follow, see <<addnl_obj_classes>>..._
|
||||
|===
|
||||
|
||||
|
||||
[[addnl_obj_classes]]
|
||||
=== Additional Object Classes
|
||||
|
||||
In addition to 3GPP TS 12.21 Chapter 9.2, the following managed objects
|
||||
are supported:
|
||||
|
||||
.Additional Managed Object Classes
|
||||
[options="header"]
|
||||
[cols="20%,20%,60%"]
|
||||
|===
|
||||
| Value | Name | Description
|
||||
| 0xf0 | GPRS NSE | GPRS-NS Entity
|
||||
| 0xf1 | GPRS CELL | GPRS Cell Entity
|
||||
| 0xf2 | GPRS NSVC | GPRS NS Virtual Circuit
|
||||
|===
|
||||
|
||||
==== GPRS-NSE Managed Object
|
||||
|
||||
There is one NS Entity per BTS. It supports the *Set Attribute* message
|
||||
with the following Information Elements:
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message Type | 3GPP TS 12.21 9.1 | M | V | 1
|
||||
| Object Class | 3GPP TS 12.21 9.2 | M | V | 1
|
||||
| Object Instance | 3GPP TS 12.21 9.3 | M | V | 3
|
||||
| GPRS NSEI | <<NM_ATT_IPACC_NSEI>> | O | TL16V | >= 5
|
||||
| GPRS NS Configuration | <<NM_ATT_IPACC_NS_LINK_CFG>> | O | TL16V | >= 10
|
||||
| GPRS BSSGP Configuration | <<NM_ATT_IPACC_BSSGP_CFG>> | O | TL16V | >= 14
|
||||
|===
|
||||
|
||||
==== GPRS Cell Managed Object
|
||||
|
||||
There is one GPRS Cell entity per BTS. It supports the *Set Attribute*
|
||||
message with the following Information Elements:
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message Type | 3GPP TS 12.21 9.1 | M | V | 1
|
||||
| Object Class | 3GPP TS 12.21 9.2 | M | V | 1
|
||||
| Object Instance | 3GPP TS 12.21 9.3 | M | V | 3
|
||||
| GPRS Routing Area Code | <<NM_ATT_IPACC_RAC>> | O | TL16V | >= 4
|
||||
| GPRS Paging Configuration | <<NM_ATT_IPACC_GPRS_PAGING_CFG>> | O | TL16V | >= 5
|
||||
| GPRS RLC Configuration | <<NM_ATT_IPACC_RLC_CFG>> | O | TL16V | >= 12
|
||||
| GPRS Coding Schemes | <<NM_ATT_IPACC_CODING_SCHEMES>> | O | TL16V | >= 5
|
||||
| GPRS RLC Configuration 2 | <<NM_ATT_IPACC_RLC_CFG_2>> | O | TL16V | >= 8
|
||||
| GPRS RLC Configuration 3 | <<NM_ATT_IPACC_RLC_CFG_3>> | O | TL16V | >= 4
|
||||
|===
|
||||
|
||||
==== GPRS NS-VC Managed Object
|
||||
|
||||
There are two GPRS NS-VC instances per BTS. It supports the *Set
|
||||
Attribute* message with the following Information Elements:
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message Type | 3GPP TS 12.21 9.1 | M | V | 1
|
||||
| Object Class | 3GPP TS 12.21 9.2 | M | V | 1
|
||||
| Object Instance | 3GPP TS 12.21 9.3 | M | V | 3
|
||||
| GPRS NSVCI | <<NM_ATT_IPACC_NSVCI>> | O | TL16V | >= 5
|
||||
| GPRS NS Link Configuration | <<NM_ATT_IPACC_NS_LINK_CFG>> | O | TL16V | >= 11
|
||||
|===
|
||||
|
||||
|
||||
=== Information Elements Overview
|
||||
|
||||
All of the IEs handled by OsmoBTS are listed below, with limitations and
|
||||
additions to TS 12.21 specified in more detail.
|
||||
|
||||
==== IEs Conforming to TS 12.21
|
||||
|
||||
The following Information Elements are accepted by OsmoBTS. Not all IEs are
|
||||
actually evaluated.
|
||||
|
||||
.IEs conforming to TS 12.21
|
||||
[options="header",cols="5%,10%,40%,5%,40%"]
|
||||
|===
|
||||
| tag (hex) | TS 12.21 § | IE name | <-/-> | Received/Sent by OsmoBTS
|
||||
| 0x00 | 9.4.1 | Abis Channel | | _ignored_
|
||||
| 0x01 | 9.4.2 | Additional Info | | _ignored_
|
||||
| 0x02 | 9.4.3 | Additional Text | | _ignored_
|
||||
| 0x03 | 9.4.4 | Administrative State | <- -> | Received & Sent
|
||||
| 0x04 | 9.4.5 | ARFCN List | <- | Received, with exactly 1 ARFCN: see <<NM_ATT_ARFCN_LIST>>;
|
||||
ignored by _Set Radio Attribute_ message (<<set_radio_attr>>)
|
||||
| 0x05 | 9.4.6 | Autonomously Report | | _ignored_
|
||||
| 0x06 | 9.4.7 | Availability Status | -> | Sent
|
||||
| 0x07 | 9.4.8 | BCCH ARFCN | <- | Received
|
||||
| 0x08 | 9.4.9 | BSIC | <- | Received
|
||||
| 0x09 | 9.4.10 | BTS Air Timer | <- | Received
|
||||
| 0x0a | 9.4.11 | CCCH Load Indication Period | <- | Received
|
||||
| 0x0b | 9.4.12 | CCCH Load Threshold | <- | Received
|
||||
| 0x0c | 9.4.13 | Channel Combination | <- | Received, with additional channel combinations: see <<ie_chan_comb>>
|
||||
| 0x0d | 9.4.14 | Connection Failure Criterion | <- | Received, with limitations see <<ie_conn_fail_crit>>
|
||||
| 0x0e | 9.4.15 | Destination | | _ignored_
|
||||
| 0x0f | 9.4.16 | Event Type | | _ignored_
|
||||
| 0x11 | 9.4.17 | File Data | | _ignored_
|
||||
| 0x12 | 9.4.18 | File Id | | _ignored_
|
||||
| 0x13 | 9.4.19 | File Version | | _ignored_
|
||||
| 0x14 | 9.4.20 | GSM Time | | _ignored_
|
||||
| 0x16 | 9.4.22 | HW Configuration | | _ignored_
|
||||
| 0x18 | 9.4.24 | Intave Parameter | <- | _ignored_
|
||||
| 0x19 | 9.4.25 | Interference level Boundaries | <- | _ignored_
|
||||
| 0x1a | 9.4.26 | List of Required Attributes | | _ignored_
|
||||
| 0x1c | 9.4.28 | Manufacturer Dependent State | | _ignored_
|
||||
| 0x1d | 9.4.29 | Manufacturer Dependent Thresholds | | _ignored_
|
||||
| 0x1e | 9.4.30 | Manufacturer Id | | _ignored_
|
||||
| 0x1f | 9.4.31 | Max Timing Advance | <- | Received
|
||||
| 0x20 | 9.4.34 | Multi-drop BSC Link | | _ignored_
|
||||
| 0x21 | 9.4.35 | Multi-drop next BTS Link | | _ignored_
|
||||
| 0x22 | 9.4.36 | Nack Causes | -> | Sent
|
||||
| 0x23 | 9.4.37 | Ny1 | <- | Received
|
||||
| 0x24 | 9.4.38 | Operational State | -> | Sent
|
||||
| 0x25 | 9.4.39 | Overload Period | <- | _ignored_
|
||||
| 0x26 | 9.4.40 | Physical Config | | _ignored_
|
||||
| 0x27 | 9.4.41 | Power Class | | _ignored_
|
||||
| 0x28 | 9.4.42 | Power Output Thresholds | | _ignored_
|
||||
| 0x29 | 9.4.43 | Probable Cause | | _ignored_
|
||||
| 0x2a | 9.4.44 | RACH Busy Threshold | <- | Received
|
||||
| 0x2b | 9.4.45 | RACH Load Averaging Slots | <- | _ignored_
|
||||
| 0x2c | 9.4.46 | Radio Sub Channel | | _ignored_
|
||||
| 0x2d | 9.4.47 | RF Max Power Reduction | <- | Received
|
||||
| 0x2e | 9.4.48 | Site Inputs | | _ignored_
|
||||
| 0x2f | 9.4.49 | Site Outputs | | _ignored_
|
||||
| 0x30 | 9.4.50 | Source | | _ignored_
|
||||
| 0x31 | 9.4.51 | Specific Problems | | _ignored_
|
||||
| 0x33 | 9.4.53 | T200 | <- | _ignored_ (1s on DCCH, 2s on ACCH)
|
||||
| 0x34 | 9.4.54 | TEI | | _ignored_
|
||||
| 0x35 | 9.4.55 | Test Duration | | _ignored_
|
||||
| 0x36 | 9.4.56 | Test No | | _ignored_
|
||||
| 0x37 | 9.4.57 | Test Report Info | | _ignored_
|
||||
| 0x38 | 9.4.58 | VSWR Thresholds | | _ignored_
|
||||
| 0x39 | 9.4.59 | Window Size | | _ignored_
|
||||
| 0x40 | 9.4.60 | TSC | <- | Received, with limitations: see <<NM_ATT_TSC>>
|
||||
| 0x41 | 9.4.61 | SW Configuration | | _ignored_
|
||||
| 0x43 | 9.4.63 | Perceived Severity | | _ignored_
|
||||
| 0x44 | 9.4.64 | Get Attribute Response Info | | _ignored_
|
||||
| 0x45 | 9.4.65 | Outstanding Alarm Sequence | | _ignored_
|
||||
| 0x46 | 9.4.66 | HW Conf Change Info | | _ignored_
|
||||
| 0x47 | 9.4.32 | Measurement Result | | _ignored_
|
||||
|===
|
||||
|
||||
==== IEs Not Conforming to TS 12.21
|
||||
|
||||
.IEs not conforming to TS 12.21
|
||||
[options="header",cols="5%,10%,30%,55%"]
|
||||
|===
|
||||
| tag (hex) | TS 12.21 § | IE name | Description
|
||||
| 0x15 | 9.4.21 | HSN | presence causes NACK response
|
||||
| 0x17 | 9.4.23 | HW Description | _ignored_ by OsmoBTS, but coding may differ, see <<ie_hw_desc>>
|
||||
| 0x1b | 9.4.27 | MAIO | presence causes NACK response
|
||||
| 0x32 | 9.4.52 | Starting Time | presence causes NACK response
|
||||
| 0x42 | 9.4.62 | SW Description | not supported
|
||||
| 0x48 | 9.4.33 | Measurement Type | not supported
|
||||
|===
|
||||
|
||||
|
||||
==== Additional Attributes and Parameters
|
||||
|
||||
The following Information Elements are defined in addition to those
|
||||
specified in 3GPP TS 12.21 Chapter 9.4.
|
||||
|
||||
All of these additional IEs are _received_ by OsmoBTS.
|
||||
|
||||
The content of these attributes is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
.Additional IEs handled by OsmoBTS but not defined in TS 12.21
|
||||
[options="header",cols="5%,50%,45%"]
|
||||
|===
|
||||
| tag (hex) | IE name | Description
|
||||
| 0x80 | RSL Destination IP Address | <<NM_ATT_IPACC_DST_IP>>
|
||||
| 0x81 | RSL Destination TCP Port | <<NM_ATT_IPACC_DST_IP_PORT>>
|
||||
| 0x85 | RSL IPA Stream ID | <<NM_ATT_IPACC_STREAM_ID>>
|
||||
| 0x9a | GPRS Routing Area Code | <<NM_ATT_IPACC_RAC>>
|
||||
| 0x9c | GPRS Paging Configuration | <<NM_ATT_IPACC_GPRS_PAGING_CFG>>
|
||||
| 0x9d | GPRS NSEI | <<NM_ATT_IPACC_NSEI>>
|
||||
| 0x9e | GPRS BVCI | <<NM_ATT_IPACC_BVCI>>
|
||||
| 0x9f | GPRS NSVCI | <<NM_ATT_IPACC_NSVCI>>
|
||||
| 0xa0 | GPRS NS Configuration | <<NM_ATT_IPACC_NS_CFG>>
|
||||
| 0xa1 | GPRS BSSGP Configuration | <<NM_ATT_IPACC_BSSGP_CFG>>
|
||||
| 0xa2 | GPRS NS Link Configuration | <<NM_ATT_IPACC_NS_LINK_CFG>>
|
||||
| 0xa3 | GPRS RLC Configuration | <<NM_ATT_IPACC_RLC_CFG>>
|
||||
| 0xa8 | GPRS Coding Schemes | <<NM_ATT_IPACC_CODING_SCHEMES>>
|
||||
| 0xa9 | GPRS RLC Configuration 2 | <<NM_ATT_IPACC_RLC_CFG_2>>
|
||||
| 0xac | GPRS RLC Configuration 3 | <<NM_ATT_IPACC_RLC_CFG_3>>
|
||||
|===
|
||||
|
||||
|
||||
=== Details on IEs
|
||||
|
||||
[[ie_hw_desc]]
|
||||
==== HW Description
|
||||
|
||||
TS 12.21 suggests a series of 5 length-value pairs for the _HW Description_ IE.
|
||||
Instead, OsmoBTS interprets it as a single TL16V. The value of this IE is
|
||||
ignored by OsmoBTS, yet the coding may affect message parsing.
|
||||
|
||||
[width="40%",cols="90%,10%"]
|
||||
[grid="none"]
|
||||
|===
|
||||
| Attribute Identifier (0x17) | 1
|
||||
| Length | 2-3
|
||||
| Ignored | N
|
||||
|===
|
||||
|
||||
|
||||
[[NM_ATT_ARFCN_LIST]]
|
||||
==== ARFCN List
|
||||
|
||||
Since OsmoBTS does not support frequency hopping, the _ARFCN List_ must contain
|
||||
exactly one ARFCN.
|
||||
|
||||
[[ie_chan_comb]]
|
||||
==== Additional Channel Combinations
|
||||
|
||||
In addition to 3GPP TS 12.21 Chapter 9.4.13, the following channel
|
||||
combinations are supported:
|
||||
|
||||
.Additional Channel Combinations
|
||||
[options="header"]
|
||||
[cols="10%,90%"]
|
||||
|===
|
||||
| Value | Description
|
||||
| 0x0b | Reserved for PBCCH + PCCCH + PDTCH/F + PACCH/F + PTCCH/F
|
||||
| 0x0c | Reserved for PBCCH + PDTCH/F + PACCH/F + PTCCH/F
|
||||
| 0x0d | PDTCH/F + PACCH/F + PTCCH/F
|
||||
| 0x80 | Reserved for Dynamic TCH/F / PDCH
|
||||
| 0x81 | Reserved for Dynamic TCH/F / TCH/H
|
||||
|===
|
||||
|
||||
[[ie_conn_fail_crit]]
|
||||
==== Connection Fail Criterion
|
||||
|
||||
3GPP TS 12.21 Chapter 9.4.14 specifies two different options for the
|
||||
_Connection Failure Criterion_. OsmoBTS only implements the option
|
||||
coded as 0x01, i.e. based upon uplink SACCH error rate
|
||||
(RADIO_LINK_TIMEOUT).
|
||||
|
||||
[[NM_ATT_TSC]]
|
||||
==== TSC
|
||||
|
||||
Due to limitations in the currently supported PHY implementations,
|
||||
OsmoBTS supports only one global TSC for all channels on one TRX, rather
|
||||
than a separate TSC for each timeslot, as expected by 3GPP TS 12.21.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_DST_IP]]
|
||||
==== RSL Destination IP Address
|
||||
|
||||
The value part of this attribute has a length of 4 octets and is encoded
|
||||
as IPv4 address in network byte order.
|
||||
|
||||
[width="40%",cols="90%,10%"]
|
||||
[grid="none"]
|
||||
|===
|
||||
| Attribute Identifier (0x80) | 1
|
||||
| IPv4 Address (MSB first) | 2-5
|
||||
|===
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_DST_IP_PORT]]
|
||||
==== RSL Destination TCP Port
|
||||
|
||||
The value part of this attribute has a length of 2 octets and contains
|
||||
the TCP destination port for the RSL connection, encoded in network byte
|
||||
order.
|
||||
|
||||
[width="40%",cols="90%,10%"]
|
||||
[grid="none"]
|
||||
|===
|
||||
| Attribute Identifier (0x81) | 1
|
||||
| Port number (MSB first) | 2-3
|
||||
|===
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_STREAM_ID]]
|
||||
==== RSL IPA Stream ID
|
||||
|
||||
The value part of this attribute has a length of one octet and specifies
|
||||
the IPA stream ID to be used for the RSL connection of this TRX.
|
||||
|
||||
[width="40%",cols="90%,10%"]
|
||||
[grid="none"]
|
||||
|===
|
||||
| Attribute Identifier (0x85) | 1
|
||||
| Stream ID | 2
|
||||
|===
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_RAC]]
|
||||
==== GPRS Routing Area Code
|
||||
|
||||
The value part of the GPRS Routing Area code consist of a single octet
|
||||
encoding the GPRS Routing Area Code.
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_GPRS_PAGING_CFG]]
|
||||
==== GPRS Paging Configuration
|
||||
|
||||
The value part of this attribute consists of two octets encoded as
|
||||
follows:
|
||||
|
||||
[options="header"]
|
||||
[cols="10%,90%"]
|
||||
|===
|
||||
| Offset | Description
|
||||
| 0 | GPRS Paging repeat time in units of 50ms intervals
|
||||
| 1 | GPRS Paging repeat count
|
||||
|===
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_NSEI]]
|
||||
==== GPRS NSEI
|
||||
|
||||
The value part of the GPRS NSEI is encoded as 16bit integer value in
|
||||
network byte order.
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_BVCI]]
|
||||
==== GPRS BVCI
|
||||
|
||||
The value part of this attribute consists of two octets encoding the
|
||||
BSSGP Virtual Circuit Identifier (BVCI) as unsigned 16 bit integer in
|
||||
network byte order.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_NSVCI]]
|
||||
==== GPRS NSVCI
|
||||
|
||||
The value part of the GPRS NSVCI attribute is a 16bit unsigned integer
|
||||
in network byte order, encoding the GPRS NSVCI as specified in 3GPP TS
|
||||
08.16.
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_NS_CFG]]
|
||||
==== GPRS NS Configuration
|
||||
|
||||
The value part of the GPRS NS Configuration consist of an array of 7 octets, each
|
||||
describing one GPRS NS related timer:
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_BSSGP_CFG]]
|
||||
==== GPRS BSSGP Configuration
|
||||
|
||||
The value part of the GPRS BSSGP configuration consists of an array of
|
||||
11 octets, each describing one GPRS BSSGP related timer:
|
||||
|
||||
[options="header"]
|
||||
[cols="10%,90%"]
|
||||
|===
|
||||
| Offset | Description
|
||||
| 0 | Blocking Timer (T1)
|
||||
| 1 | Blocking Retries
|
||||
| 2 | Unblocking Retries
|
||||
| 3 | Reset Timer (T2)
|
||||
| 4 | Reset Retries
|
||||
| 5 | Suspend Timer (T3) in units of 100ms
|
||||
| 6 | Suspend Retries
|
||||
| 7 | Resume Timer (T4) in units of 100ms
|
||||
| 8 | Resume Retries
|
||||
| 9 | Capability Update Timer (T5)
|
||||
| 10 | Capability Update Retries
|
||||
|===
|
||||
|
||||
The detailed description of the meaning of those timers is given in the
|
||||
GPRS BSSGP specification 3GPP TS 08.18.
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_NS_LINK_CFG]]
|
||||
==== GPRS NS Link Configuration
|
||||
|
||||
The content of this attribute is 8 octets long and encoded as follows:
|
||||
[options="header"]
|
||||
[cols="10%,10%,80%"]
|
||||
|===
|
||||
| Offset | Length | Description
|
||||
| 0 | 2 | GPRS-NS Remote UDP Port Number (SGSN side)
|
||||
| 2 | 4 | GPRS-NS Remote IPv4 Address (SGSN side)
|
||||
| 6 | 2 | GPRS-NS Local UDP Port Number (BTS side)
|
||||
|===
|
||||
|
||||
All values are encoded in network byte order.
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_RLC_CFG]]
|
||||
==== GPRS RLC Configuration
|
||||
|
||||
The value part of the GPRS RLC Configuration consists of an array of 9
|
||||
octets, each describing a RLC timer:
|
||||
|
||||
[options="header"]
|
||||
[width="60%",cols="10%,80%,10%"]
|
||||
|===
|
||||
| Offset | Description | Unit
|
||||
| 0 | GPRS RLC Timer T3142 | s
|
||||
| 1 | GPRS RLC Timer T3169 | s
|
||||
| 2 | GPRS RLC Timer T3191 | s
|
||||
| 3 | GPRS RLC Timer T3193 | 10ms
|
||||
| 4 | GPRS RLC Timer T3195 | s
|
||||
| 5 | GPRS RLC Timer T3101 | s
|
||||
| 6 | GPRS RLC Timer T3103 | s
|
||||
| 7 | GPRS RLC Timer T3105 | s
|
||||
| 8 | GPRS RLC CV Countdown | -
|
||||
|===
|
||||
|
||||
The meaning of the RLC timers are specified in 3GPP TS 04.60.
|
||||
|
||||
The countdown value specifies the RLC CV value from which the countdown
|
||||
procedure is started.
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_CODING_SCHEMES]]
|
||||
==== GPRS Coding Schemes
|
||||
|
||||
The value part of the GPRS Coding Schemes consists of two octets
|
||||
encoding the available GPRS and EDGE coding schemes.
|
||||
|
||||
[options="header"]
|
||||
|===
|
||||
| *bit* | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
|
||||
| byte at offset 0 | MCS9 | x | x | x | CS4 | CS3 | CS2 | CS1
|
||||
| byte at offset 1 | MCS8 | MCS7| MCS6 | MCS5 | MCS4| MCS3 | MCS2 | MCS1
|
||||
|===
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_RLC_CFG_2]]
|
||||
==== GPRS RLC Configuration 2
|
||||
|
||||
The value part of this attribute is 8 octets long and encoded as
|
||||
follows:
|
||||
[options="header"]
|
||||
[width="60%",cols="10%,10%,70%,10%"]
|
||||
|===
|
||||
| Offset | Length | Description | Unit
|
||||
| 0 | 2 | Downlink TBF Extension Timer | 10ms
|
||||
| 2 | 2 | Uplink TBF Extension Timer | 10ms
|
||||
| 4 | 2 | Initial GPRS Coding Scheme | -
|
||||
|===
|
||||
|
||||
The Initial GPRS Coding Scheme is encoded as follows:
|
||||
[options="header"]
|
||||
[width="40%",cols="50%,50%"]
|
||||
|===
|
||||
| Value | Description
|
||||
| 1 | CS 1
|
||||
| 2 | CS 2
|
||||
| 3 | CS 3
|
||||
| 4 | CS 4
|
||||
|===
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
|
||||
[[NM_ATT_IPACC_RLC_CFG_3]]
|
||||
==== GPRS RLC Configuration 3
|
||||
|
||||
The content of this attribute contains information about the initial MCS
|
||||
used for new EDGE TBFs.
|
||||
|
||||
It is encoded as follows:
|
||||
[options="header"]
|
||||
[width="40%",cols="50%,50%"]
|
||||
|===
|
||||
| Value | Description
|
||||
| 1 | MCS 1
|
||||
| 2 | MCS 2
|
||||
| 3 | MCS 3
|
||||
| 4 | MCS 4
|
||||
| 5 | MCS 5
|
||||
| 6 | MCS 6
|
||||
| 7 | MCS 7
|
||||
| 8 | MCS 8
|
||||
| 9 | MCS 9
|
||||
|===
|
||||
|
||||
The content of this attribute is not used by OsmoBTS, but
|
||||
simply passed to OsmoPCU connected to the PCU socket.
|
||||
|
||||
=== A-bis OML Initialization / BTS bring-up
|
||||
|
||||
At the time an Abis/IP BTS connects to via OML to the BSC, it is
|
||||
initialized according to the procedures described in 3GPP TS 12.21 as
|
||||
amended in this document.
|
||||
|
||||
Each Managed Object (MO) is separately initialized. The initialization
|
||||
sequence and parameters differ slightly depending on the MO involved.
|
||||
|
||||
Some parts of the sequences described below are optional, such as the
|
||||
Software activation. In the OsmoBTS case, the software is nod modular
|
||||
and thus all MOs start with the software fully activated. Thus, no
|
||||
__Software Activate Request__ is being sent by the MO to the BSC, nor
|
||||
does the BSC need to initialize the __Activate Software__ procedure.
|
||||
|
||||
Still, the full sequences are shown in order to explain the Abis/IP
|
||||
protocol.
|
||||
|
||||
Also, the initial state of the MOs at time of OML connection
|
||||
initialization is not always guaranteed to be Disabled/Notinstalled.
|
||||
Rather, the BSC implementation has to deal with the initial state as
|
||||
reported by the MOs at time of re-connection.
|
||||
|
||||
==== Site Manager MO Initialization
|
||||
|
||||
.A-bis OML Initialization of Site Manager MO
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-mo-sitemgr.msc[]
|
||||
----
|
||||
|
||||
As the Site Manager MO does not depend on other MOs, nor does it have an
|
||||
Administrative state (__Locked/Unlocked__), it immediately ends up in the
|
||||
__Enabled__ state.
|
||||
|
||||
==== BTS MO Initialization
|
||||
|
||||
.A-bis OML Initialization of BTS MO
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-mo-bts.msc[]
|
||||
----
|
||||
|
||||
As can be seen in the BTS MO, its state is
|
||||
|
||||
* Availability state __Dependency__, meaning it depends on other MOs to
|
||||
be initialized before becoming enabled.
|
||||
* Administrative state __Locked__, as the object is first waiting to
|
||||
receive attributes in the __Locked__ state, before the __Change
|
||||
Administrative State (Unlocked)__ procedure is used to request
|
||||
transitioning into Unlocked state.
|
||||
|
||||
==== Baseband Transceiver MO Initialization
|
||||
|
||||
.A-bis OML Initialization of Baseband Transceiver MO
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-mo-transceiver.msc[]
|
||||
----
|
||||
|
||||
There is one Baseband Transceiver MO per TRX in the BTS. For a
|
||||
multi-TRX BTS, the above procedure must be repeated for each TRX.
|
||||
|
||||
|
||||
==== Radio Carrier MO Initialization
|
||||
|
||||
.A-bis OML Initialization of Radio Carrier MO
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-mo-carrier.msc[]
|
||||
----
|
||||
|
||||
There is one Radio Carrier MO per TRX in the BTS. For a multi-TRX BTS,
|
||||
the above procedure must be repeated for each TRX.
|
||||
|
||||
|
||||
==== Channel MO Initialization
|
||||
|
||||
.A-bis OML Initialization of Radio Carrier MO
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-mo-channel.msc[]
|
||||
----
|
||||
|
||||
There are 8 Timeslots in each TRX, and correspondingly 8 Channel MOs in
|
||||
every TRX. The above procedure must thus be repeated for each timeslot
|
||||
in each transceiver of the BTS.
|
||||
|
||||
|
||||
==== Full Initialization of entire BTS
|
||||
|
||||
Some of the steps are optional, as is their detailed ordering. In
|
||||
reality, the procedures for different MOs may overlap. The message
|
||||
sequence charts in this document have been hand-crafted to avoid such
|
||||
overlap for the sake of clarity.
|
||||
|
||||
[[oml-msc-1]]
|
||||
.A-bis OML BTS bring-up (1/3)
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-startup.msc[]
|
||||
----
|
||||
|
||||
As can be seen in <<oml-msc-1>>, after the OML TCP connection is
|
||||
established
|
||||
|
||||
. the identity is exchanged via IPA CCM,
|
||||
. the BTS sends an 'OML EVENT STATE CHANGED REPORT' for every
|
||||
Managed Object
|
||||
. the BTS subsequently requests the activation of its 'Site Manager' Object
|
||||
which the BSC performs by the 'Activate SW' command.
|
||||
. After successful activation of the software in the Site Manager,
|
||||
.. the state changes to 'Enabled', and an event report is generated
|
||||
accordingly
|
||||
.. the BSC is notified about the SW activation in an associated report
|
||||
. Finally, the BSC requests the start of the Site Manager
|
||||
.. using the 'OPSTART' command,
|
||||
.. which is subsequently acknowledged by the Site Manager.
|
||||
|
||||
[[oml-msc-2]]
|
||||
.A-bis OML BTS bring-up (2/3)
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-startup2.msc[]
|
||||
----
|
||||
|
||||
[[oml-msc-3]]
|
||||
.A-bis OML BTS bring-up (3/3)
|
||||
["mscgen"]
|
||||
----
|
||||
include::oml-startup3.msc[]
|
||||
----
|
||||
|
||||
In <<oml-msc-2>>, we can see
|
||||
|
||||
. Software Activation and associated state transitions of the BTS MO
|
||||
. Setting of the BTS Attributes followed by OPSTART
|
||||
. Software Activation and associated state transitions of the 'Baseband
|
||||
Transceiver' MO
|
||||
. Software Activation and associated state transitions of the 'Radio
|
||||
Carrier' MO
|
||||
. Once the 'Baseband Transceiver' MO has its software activated, the
|
||||
'Channel' MOs (one for each timeslot) indicate their state change and
|
||||
software activation, too.
|
||||
|
||||
In <<oml-msc-3>>, we can see
|
||||
|
||||
. The 'Radio Carrier' MO Software Activation
|
||||
. The Request to the 'Baseband Transceiver' MO to establish the RSL
|
||||
signalling connection to the BSC.
|
||||
. Subsequent OPSTART and Change of Administrative State on the 'Baseband
|
||||
Transceiver' MO
|
||||
. The following procedure for each of the 'Channel' MOs:
|
||||
.. Setting the Channel Attributes (such as channel combination)
|
||||
.. OPSTART
|
||||
.. Changing the Administrative State to Unlocked
|
||||
.. Subsequent State Change Event Report with the new state
|
||||
. After all 'Channel' MOs are initialized, the Radio Carrier goes through
|
||||
a similar procedure of
|
||||
.. Setting its attributes
|
||||
.. OPSTART
|
||||
.. Changing its Administrative State to Unlocked
|
||||
.. Subsequent State Change Event Report with the new State (Enabled/OK)
|
||||
. All 'Channel' MOs now also report their state as Enabled/OK
|
||||
. Finally, the BTS reports its state as Enabled/OK
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
msc {
|
||||
bts [label="TRX"], bsc [label="BSC"];
|
||||
|
||||
bts => bsc [label="TCP Connect (Port 3003, RSL)"];
|
||||
bts box bsc [label="IPA CCM Identification (Port 3003)"];
|
||||
|||;
|
||||
|
||||
bts <= bsc [label="BCCH Information (SI1)"];
|
||||
bts <= bsc [label="BCCH Information (SI2)"];
|
||||
...;
|
||||
bts <= bsc [label="BCCH Information (SI3)"];
|
||||
bts <= bsc [label="BCCH Information (SI4)"];
|
||||
|||;
|
||||
bts <= bsc [label="SACCH FILLING (SI5)"];
|
||||
...;
|
||||
bts <= bsc [label="SACCH FILLING (SI6)"];
|
||||
|||;
|
||||
bts => bsc [label="RF Resource Indication"];
|
||||
...;
|
||||
bts => bsc [label="RF Resource Indication"];
|
||||
...;
|
||||
}
|
|
@ -0,0 +1,16 @@
|
|||
msc {
|
||||
bts [label="TRX"], bsc [label="BSC"];
|
||||
|
||||
bts => bsc [label="TCP Connect (Port 3003, RSL)"];
|
||||
bts box bsc [label="IPA CCM Identification (Port 3003)"];
|
||||
|||;
|
||||
|
||||
bts <= bsc [label="SACCH FILLING (SI5)"];
|
||||
...;
|
||||
bts <= bsc [label="SACCH FILLING (SI6)"];
|
||||
|||;
|
||||
bts => bsc [label="RF Resource Indication"];
|
||||
...;
|
||||
bts => bsc [label="RF Resource Indication"];
|
||||
...;
|
||||
}
|
|
@ -0,0 +1,56 @@
|
|||
msc {
|
||||
hscale = 2;
|
||||
|
||||
ms [label="MS"], bts [label="BTS"], bsc [label="BSC"], Msc [label="MSC"], mgw [label="MGW"];
|
||||
|
||||
ms => bts [label="L1 RACH burst"];
|
||||
bts => bsc [label="RSL CHAN RQD"];
|
||||
bts <= bsc [label="RSL CHAN ACT"];
|
||||
bts => bsc [label="RSL CHAN ACT ACK"];
|
||||
bts <= bsc [label="RSL IMM ASS CMD (RR IMM ASS)"];
|
||||
ms <= bts [label="RR IMMEDIATE ASSIGN"];
|
||||
ms => bts [label="LAPDm SABM (CM SERVICE REQ)"];
|
||||
ms <= bts [label="LAPDm FIXME"];
|
||||
bts => bsc [label="RSL ESTABLISH IND (CM SERVICE REQ)"];
|
||||
bsc => Msc [label="CR (BSSAP COMPLETE L3 (CM SERVICE REQ))"];
|
||||
...;
|
||||
ms box Msc [label="MM Common Procedures (INFO, ID, AUTH, CIPH)"];
|
||||
...;
|
||||
ms => bts [label="CC SETUP"];
|
||||
bts => bsc [label="RSL DATA IND (CC SETUP)"];
|
||||
bsc => Msc [label="DT1 (DTAP (CC SETUP))"];
|
||||
...;
|
||||
ms box Msc [label="CC Signalling"];
|
||||
...;
|
||||
bsc <= Msc [label="BSSAP ASSIGNMENT CMD (TCH)"];
|
||||
bts <= bsc [label="RSL IPA CRCX", id="1"];
|
||||
bts => bsc [label="RSL IPA CRCX ACK (IP/Port @ BTS)"];
|
||||
bsc => Msc [label="FIXME"];
|
||||
Msc => mgw [label="FIXME"];
|
||||
bts <- mgw [label="Start RTP + RTCP UDP Flows"];
|
||||
|
||||
bts <= bsc [label="RSL DATA REQ (RR CHAN MOD MODIFY)"];
|
||||
ms <= bts [label="RR CHAN MOD MODIFY"];
|
||||
ms => bts [label="RR CHAN MOD MODIFY ACK"];
|
||||
bts => bsc [label="RSL DATA IND (RR CHAN MOD MODIFY ACK)"];
|
||||
|||;
|
||||
bts <= bsc [label="RSL MODE MODIFY REQ"];
|
||||
bts => bsc [label="RSL MODE MODIFY ACK"];
|
||||
|
||||
Msc <= mgw [label="FIXME"];
|
||||
bsc <= Msc [label="FIXME"];
|
||||
bts <= bsc [label="RSL IPA MDCX (IP/Port @ MGW)", id="2"];
|
||||
bts => bsc [label="RSL IPA MDCX ACK"];
|
||||
|
||||
bts -> mgw [label="Start RTP + RTCP UDP Flows"];
|
||||
ms box mgw [label="Active Voice Call"];
|
||||
bts => bsc [label="RSL MEAS RES"];
|
||||
...;
|
||||
|
||||
bts <= bsc [label="RSL IPA DLCX"];
|
||||
bts => bsc [label="RSL IPA DLCX ACK"];
|
||||
bts -x mgw [label="Stop RTP + RTCP UDP Flows"];
|
||||
|
||||
bts <= bsc [label="RSL RF CHAN REL"];
|
||||
bts => bsc [label="RSL RF CHAN REL ACK"];
|
||||
}
|
|
@ -0,0 +1,681 @@
|
|||
== Radio Signalling Link (RSL)
|
||||
|
||||
=== List of Messages
|
||||
|
||||
The following tables list the RSL messages used by OsmoBTS A-bis/IP,
|
||||
grouped by their level of compliance with 3GPP TS 08.58.
|
||||
|
||||
==== Messages Compliant With TS 08.58
|
||||
|
||||
Specific limitations apply, see the linked sections.
|
||||
|
||||
.Messages compliant with TS 08.58
|
||||
[options="header",cols="10%,20%,45%,5%,20%"]
|
||||
|===
|
||||
| TS 08.58 § | This document § | Message | <-/-> | Received/Sent by OsmoBTS
|
||||
5+<| *Radio link layer management messages*
|
||||
| 8.3.1 | - | DATA REQUEST | <- | Received
|
||||
| 8.3.2 | - | DATA INDICATION | -> | Sent
|
||||
| 8.3.3 | - | ERROR INDICATION | -> | Sent
|
||||
| 8.3.4 | - | ESTABLISH REQUEST | <- | Received
|
||||
| 8.3.5 | - | ESTABLISH CONFIRM | -> | Sent
|
||||
| 8.3.6 | - | ESTABLISH INDICATION | -> | Sent
|
||||
| 8.3.7 | - | RELEASE REQUEST | <- | Received
|
||||
| 8.3.8 | - | RELEASE CONFIRM | -> | Sent
|
||||
| 8.3.9 | - | RELEASE INDICATION | -> | Sent
|
||||
| 8.3.10 | - | UNIT DATA REQUEST | <- | Received
|
||||
| 8.3.11 | - | UNIT DATA INDICATION | -> | Sent
|
||||
5+<| *DEDICATED CHANNEL MANAGEMENT MESSAGES*
|
||||
| 8.4.1 | - | CHANNEL ACTIVATION | <- | Received
|
||||
| 8.4.2 | - | CHANNEL ACTIVATION ACKNOWLEDGE | -> | Sent
|
||||
| 8.4.3 | - | CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE | -> | Sent
|
||||
| 8.4.4 | - | CONNECTION FAILURE INDICATION | -> | Sent
|
||||
| 8.4.5 | - | DEACTIVATE SACCH | <- | Received
|
||||
| 8.4.6 | - | ENCRYPTION COMMAND | <- | Received
|
||||
| 8.4.7 | - | HANDOVER DETECTION | -> | Sent
|
||||
| 8.4.8 | <<MEASUREMENT_RESULT>> | MEASUREMENT RESULT | -> | Sent
|
||||
| 8.4.9 | <<MODE_MODIFY>> | MODE MODIFY | <- | Received
|
||||
| 8.4.10 | - | MODE MODIFY ACKNOWLEDGE | -> | Sent
|
||||
| 8.4.11 | - | MODE MODIFY NEGATIVE ACKNOWLEDGE | -> | Sent
|
||||
| 8.4.14 | - | RF CHANNEL RELEASE | <- | Received
|
||||
| 8.4.15 | <<MS_POWER_CONTROL>> | MS POWER CONTROL | <- | Received
|
||||
| 8.4.19 | - | RF CHANNEL RELEASE ACKNOWLEDGE | -> | Sent
|
||||
| 8.4.20 | <<SACCH_INFO_MODIFY>> | SACCH INFO MODIFY | <- | Received
|
||||
5+<| *COMMON CHANNEL MANAGEMENT MESSAGES*
|
||||
| 8.5.1 | <<BCCH_INFORMATION>> | BCCH INFORMATION | <- | Received
|
||||
| 8.5.2 | - | CCCH LOAD INDICATION | -> | Sent
|
||||
| 8.5.3 | <<CHANNEL_REQUIRED>> | CHANNEL REQUIRED | -> | Sent
|
||||
| 8.5.5 | <<PAGING_COMMAND>> | PAGING COMMAND | <- | Received
|
||||
| 8.5.6 | - | IMMEDIATE ASSIGN COMMAND | <- | Received
|
||||
| 8.5.8 | <<SMS_BROADCAST_COMMAND>> | SMS BROADCAST COMMAND | <- | Received
|
||||
5+<| *TRX MANAGEMENT MESSAGES*
|
||||
| 8.6.1 | <<RF_RESOURCE_INDICATION>> | RF RESOURCE INDICATION | -> | Sent
|
||||
| 8.6.2 | <<SACCH_FILLING>> | SACCH FILLING | <- | Received
|
||||
| 8.6.4 | - | ERROR REPORT | -> | Sent
|
||||
|===
|
||||
|
||||
==== Messages Specific to OsmoBTS
|
||||
|
||||
.Messages specific to OsmoBTS, not found in 3GPP TS 08.58
|
||||
[options="header",cols="15%,15%,45%,5%,20%"]
|
||||
|===
|
||||
2+| This document § | Message | <-/-> | Received/Sent by OsmoBTS
|
||||
5+<| *User Plane Transport Management* (<<user_plane_txp_mgmt>>)
|
||||
.3+.| <<rsl_crcx>> | <<rsl_crcx_msg>> | RSL Create Connection (CRCX) | <- | Received
|
||||
| <<rsl_crcx_msg_ack>> | RSL Create Connection (CRCX) ACK | -> | Sent
|
||||
| <<rsl_crcx_msg_nack>> | RSL Create Connection (CRCX) NACK | -> | Sent
|
||||
.3+.| <<rsl_mdcx>> | <<rsl_mdcx_msg>> | RSL Modify Connection (MDCX) | <- | Received
|
||||
| <<rsl_mdcx_msg_ack>> | RSL Modify Connection (MDCX) ACK | -> | Sent
|
||||
| <<rsl_mdcx_msg_nack>> | RSL Modify Connection (MDCX) NACK | -> | Sent
|
||||
.3+.| <<rsl_dlcx>> | <<rsl_dlcx_msg>> | RSL Delete Connection (DLCX) | <- | Received
|
||||
| <<rsl_dlcx_msg_ack>> | RSL Delete Connection (DLCX) ACK | -> | Sent
|
||||
| <<rsl_dlcx_msg_nack>> | RSL Delete Connection (DLCX) NACK | -> | Sent
|
||||
| <<rsl_dlcx_ind>> | <<rsl_dlcx_ind_msg>> | RSL Delete Connection (DLCX) Indication | -> | Sent
|
||||
|===
|
||||
|
||||
==== Messages Not Implemented by OsmoBTS
|
||||
|
||||
.3GPP TS 08.58 messages not implemented by OsmoBTS
|
||||
[options="header",cols="10%,90%"]
|
||||
|===
|
||||
| TS 08.58 § | Message
|
||||
2+<| *DEDICATED CHANNEL MANAGEMENT MESSAGES*
|
||||
| 8.4.12 | PHYSICAL CONTEXT REQUEST
|
||||
| 8.4.13 | PHYSICAL CONTEXT CONFIRM
|
||||
| 8.4.16 | BS POWER CONTROL
|
||||
| 8.4.17 | PREPROCESS CONFIGURE
|
||||
| 8.4.18 | PREPROCESSED MEASUREMENT RESULT
|
||||
| 8.4.21 | TALKER DETECTION
|
||||
| 8.4.22 | LISTENER DETECTION
|
||||
| 8.4.23 | REMOTE CODEC CONFIGURATION REPORT
|
||||
| 8.4.24 | ROUND TRIP DELAY REPORT
|
||||
| 8.4.25 | PRE-HANDOVER NOTIFICATION
|
||||
| 8.4.26 | MULTIRATE CODEC MODIFICATION REQUEST
|
||||
| 8.4.27 | MULTIRATE CODEC MODIFICATION ACKNOLEWDGE
|
||||
| 8.4.28 | MULTIRATE CODEC MODIFICATION NEGATIVE ACKNOWLEDGE
|
||||
| 8.4.29 | MULTIRATE CODEC MODIFICATION PERFORMED
|
||||
| 8.4.30 | TFO REPORT
|
||||
| 8.4.31 | TFO MODIFICATION REQUEST
|
||||
2+<| *COMMON CHANNEL MANAGEMENT MESSAGES*
|
||||
| 8.5.4 | DELETE INDICATION
|
||||
| 8.5.7 | SMS BROADCAST REQUEST
|
||||
| 8.5.9 | CBCH LOAD INDICATION
|
||||
| 8.5.10 | NOTIFICATION COMMAND
|
||||
2+<| *TRX MANAGEMENT MESSAGES*
|
||||
| 8.6.3 | OVERLOAD
|
||||
2+<| *LOCATION SERVICES MESSAGES*
|
||||
| 8.7.1 | LOCATION INFORMATION
|
||||
|===
|
||||
|
||||
|
||||
=== Message Limitation Details
|
||||
|
||||
[[MEASUREMENT_RESULT]]
|
||||
==== Measurement Result
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.4.8 with this limitation:
|
||||
|
||||
._Measuremet Result_ IE limitations
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.37 | MS Timing Offset | never sent by OsmoBTS
|
||||
|===
|
||||
|
||||
[[MODE_MODIFY]]
|
||||
==== Mode Modify
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.4.9 with these limitations:
|
||||
|
||||
._Mode Modify_ IE limitations
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.45 | Main channel reference | _ignored_
|
||||
| 9.3.53 | MultiRate Control | _ignored_
|
||||
| 9.3.54 | Supported Codec Types | _ignored_
|
||||
|===
|
||||
|
||||
[[MS_POWER_CONTROL]]
|
||||
==== MS Power Control
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.4.15 with these limitations:
|
||||
|
||||
._MS Power Control_ IE limitations
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.31 | MS Power Parameters | _ignored_
|
||||
|===
|
||||
|
||||
|
||||
[[SACCH_INFO_MODIFY]]
|
||||
==== SACCH Info Modify
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.4.20, with these exceptions:
|
||||
|
||||
._SACCH Info Modify_ IE limitations
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.30 | System Info Type | See below for available types
|
||||
| 9.3.23 | Starting Time | not supported, provokes an _Error Report_ response
|
||||
|===
|
||||
|
||||
._System Info Type_ values that can occur on the SACCH
|
||||
[options="header",width="50%",cols="20%,80%"]
|
||||
|===
|
||||
| Value | Name
|
||||
| 0x05 | RSL_SYSTEM_INFO_5
|
||||
| 0x06 | RSL_SYSTEM_INFO_6
|
||||
| 0x0d | RSL_SYSTEM_INFO_5bis
|
||||
| 0x0e | RSL_SYSTEM_INFO_5ter
|
||||
| 0x47 | RSL_EXT_MEAS_ORDER
|
||||
| 0x48 | RSL_MEAS_INFO
|
||||
|===
|
||||
|
||||
[[BCCH_INFORMATION]]
|
||||
==== BCCH Information
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.5.1, with these limitations and extensions:
|
||||
|
||||
._BCCH Information_ IE details
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.30 | System Info Type | See <<SACCH_INFO_MODIFY>> for available types
|
||||
| 9.3.11 | L3 Info | This IE may be included instead of a 9.3.39 _Full BCCH Info_ IE.
|
||||
The _Full BCCH Info_ takes precedence over _L3 Info_.
|
||||
To stop SI transmission, both of these IEs must be omitted.
|
||||
|===
|
||||
|
||||
|
||||
[[CHANNEL_REQUIRED]]
|
||||
==== Channel Required
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.5.3, with these limitations:
|
||||
|
||||
._Channel Required_ message IE details
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.16 | Physical Context | never sent by OsmoBTS
|
||||
|===
|
||||
|
||||
|
||||
[[PAGING_COMMAND]]
|
||||
==== Paging Command
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.5.5, with these limitations:
|
||||
|
||||
._Paging Command_ message IE details
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.49 | eMLPP Priority | _ignored_
|
||||
|===
|
||||
|
||||
NOTE: If adding the identity to the paging queue fails, the BSC is not notified
|
||||
in any way.
|
||||
|
||||
[[SMS_BROADCAST_COMMAND]]
|
||||
=== SMS Broadcast Command
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.5.8, with these limitations:
|
||||
|
||||
._Broadcast Command_ message IE details
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.44 | SMSCB Channel Indicator | _ignored_
|
||||
|===
|
||||
|
||||
|
||||
[[RF_RESOURCE_INDICATION]]
|
||||
==== RF Resource Indication
|
||||
|
||||
This message does not conform to 3GPP TS 08.58 § 8.6.1, in that it omits the
|
||||
_Resource Information_ IE that would contain the actual payload data, which
|
||||
renders this message void.
|
||||
|
||||
._RF Resource Indication_ message IE exceptions
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.21 | Resource Information | OsmoBTS omits this IE, though TS 08.58
|
||||
specifies it as mandatory.
|
||||
|===
|
||||
|
||||
|
||||
[[SACCH_FILLING]]
|
||||
==== SACCH Filling
|
||||
|
||||
Conforms to 3GPP TS 08.58 § 8.6.2, with these limitations:
|
||||
|
||||
._SACCH Filling_ message IE limitations
|
||||
[options="header",cols="10%,30%,60%"]
|
||||
|===
|
||||
| TS 08.58 § | IE Name | Handling
|
||||
| 9.3.30 | System Info Type | See <<SACCH_INFO_MODIFY>> for available types
|
||||
| 9.3.23 | Starting Time | _ignored_
|
||||
|===
|
||||
|
||||
|
||||
[[user_plane_txp_mgmt]]
|
||||
=== User Plane Transport Management
|
||||
|
||||
This chapter defines the A-bis/IP specific RSL procedures that are
|
||||
introduced in addition to the 3GPP TS 08.58 standard procedures.
|
||||
|
||||
In classic A-bis over E1, user plane traffic is carried over 16kBps
|
||||
sub-slots of 64kBps E1 time-slots according to ETSI/3GPP TS 08.60. As
|
||||
the E1 line is a dedicated line between BTS and BSC, no further
|
||||
addressing information is required.
|
||||
|
||||
In A-bis/IP as described by the present document, new RSL procedures
|
||||
have been introduced in order to deal with the different properties of
|
||||
the underlying IP based transport medium.
|
||||
|
||||
[[rsl_crcx]]
|
||||
==== RSL Create Connection (CRCX)
|
||||
|
||||
This procedure is used by the BSC to request the BTS to allocate + bind
|
||||
to a BTS-local UDP port for the subsequent transmission of user-plane
|
||||
data via RTP.
|
||||
|
||||
To do so, the BSC sends the *Create Connection (CRCX)* message. In case of
|
||||
successful outcome, the BTS responds with *Create Connection (CRCX)
|
||||
ACK*. In case of any error, the BTS responds with *Create Connection
|
||||
(CRCX) NACK*.
|
||||
|
||||
See <<rsl_crcx_msg>>, <<rsl_crcx_msg_ack>>, <<rsl_crcx_msg_nack>>
|
||||
|
||||
[[rsl_mdcx]]
|
||||
==== RSL Modify Connection (MDCX)
|
||||
|
||||
This procedure is used by the BSC to request the BTS to modify an
|
||||
already-bound BTS-local UDP port for user-plane RTP. It is used in
|
||||
particular to configure the remote IP address and UDP port to which the
|
||||
BTS shall send user-plane RTP traffic. This remote address is normally
|
||||
either a Media Gateway (MGW) of some sort, but could also be the RTP
|
||||
socket of the corresponding other leg of a mobile-to-mobile call.
|
||||
|
||||
To modify a user-plane connection, the BSC sends the *Modify Connection*
|
||||
message. In case of successful outcome, the BTS responds with
|
||||
*Modify Connection (MDCX) ACK*. In case of any error, the BTS responds
|
||||
with *Modify Connection (MDCX) NACK*.
|
||||
|
||||
See <<rsl_mdcx_msg>>, <<rsl_mdcx_msg_ack>>, <<rsl_mdcx_msg_nack>>
|
||||
|
||||
[[rsl_dlcx]]
|
||||
==== RSL Delete Connection (DLCX)
|
||||
|
||||
This procedure is used by the BSC to request the BTS to delete an
|
||||
already-existing BTS-local UDP port for user-plane RTP.
|
||||
|
||||
To delete a user-plane connection, the BSC sends the *Delete Connection
|
||||
(DLCX)* message. In case of successful outcome, the BTS responds with
|
||||
*Delete Connection (DLCX) ACK*. In case of any error, the BTS responds
|
||||
with *Delete Connection (DLCX) NACK*.
|
||||
|
||||
See <<rsl_dlcx_msg>>, <<rsl_dlcx_msg_ack>>, <<rsl_dlcx_msg_nack>>
|
||||
|
||||
[[rsl_dlcx_ind]]
|
||||
==== RSL Delete Connection (DLCX) Indication
|
||||
|
||||
When a BTS-local UDP connection for user-plane RTP is automatically
|
||||
released at the time of RF CHANNEL RELEASE, the BTS sends a unilateral,
|
||||
non-acknowledged *RSL Delete Connection (DLCX) Indication* to the BSC.
|
||||
|
||||
See <<rsl_dlcx_ind_msg>>
|
||||
|
||||
|
||||
=== Message Formats and Contents
|
||||
|
||||
[[rsl_crcx_msg]]
|
||||
==== Create Connection (CRCX)
|
||||
|
||||
This message is sent by the BSC to the BTS in order to request the
|
||||
creation of a user-plane RTP connection for the specified *Channel
|
||||
number*.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Destination IP Address | <<RSL_IE_IPAC_REMOTE_IP>> | O | TV | 5
|
||||
| Destination IP Port | <<RSL_IE_IPAC_REMOTE_PORT>> | O | TV | 3
|
||||
| IP Speech Mode | <<RSL_IE_IPAC_SPEECH_MODE>> | O | TV | 2
|
||||
| RTP Payload Type 2 | <<RSL_IE_IPAC_RTP_PAYLOAD2>> | O | TV | 2
|
||||
|===
|
||||
|
||||
[[rsl_crcx_msg_ack]]
|
||||
==== Create Connection (CRCX) ACK
|
||||
|
||||
This message is sent by the BTS to the BSC in order to acknowledge the
|
||||
successful outcome of creating a user-plane RTP connection. It is sent
|
||||
in response to the *Create Connection (CRCX)*.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | M | TV | 3
|
||||
| Source IP Address | <<RSL_IE_IPAC_LOCAL_IP>> | O | TV | 5
|
||||
| Source IP Port | <<RSL_IE_IPAC_LOCAL_PORT>> | O | TV | 3
|
||||
| RTP Payload Type 2 | <<RSL_IE_IPAC_RTP_PAYLOAD2>> | O | TV | 2
|
||||
|===
|
||||
|
||||
[[rsl_crcx_msg_nack]]
|
||||
==== Create Connection (CRCX) NACK
|
||||
|
||||
This message is sent by the BTS to the BSC in order to signal the
|
||||
unsuccessful outcome of creating a user-plane RTP connection. It is
|
||||
sent in response to the *Create Connection (CRCX)*.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Destination IP Address | <<RSL_IE_IPAC_REMOTE_IP>> | O | TV | 5
|
||||
| Destination IP Port | <<RSL_IE_IPAC_REMOTE_PORT>> | O | TV | 3
|
||||
| Cause | 08.58 9.3.26 | O | TLV | >= 3
|
||||
|===
|
||||
|
||||
|
||||
[[rsl_mdcx_msg]]
|
||||
==== Modify Connection (MDCX)
|
||||
|
||||
This message is sent by the BSC to the BTS in order to modify the
|
||||
properties of a user-plane RTP connection.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | O | TV | 3
|
||||
| Destination IP Address | <<RSL_IE_IPAC_REMOTE_IP>> | O | TV | 5
|
||||
| Destination IP Port | <<RSL_IE_IPAC_REMOTE_PORT>> | O | TV | 3
|
||||
| IP Speech Mode | <<RSL_IE_IPAC_SPEECH_MODE>> | O | TV | 2
|
||||
| RTP Payload Type 2 | <<RSL_IE_IPAC_RTP_PAYLOAD2>> | O | TV | 2
|
||||
|===
|
||||
|
||||
[[rsl_mdcx_msg_ack]]
|
||||
==== Modify Connection (MDCX) ACK
|
||||
|
||||
This message is sent by the BTS to the BSC in order to acknowledge the
|
||||
successful modification of a user-plane RTP connection. It is sent in
|
||||
response to a *Modify Connection (MDCX)*
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | O | TV | 3
|
||||
| Source IP Address | <<RSL_IE_IPAC_LOCAL_IP>> | C | TV | 5
|
||||
| Source IP Port | <<RSL_IE_IPAC_LOCAL_PORT>> | C | TV | 3
|
||||
| RTP Payload Type 2 | <<RSL_IE_IPAC_RTP_PAYLOAD2>> | O | TV | 2
|
||||
|===
|
||||
|
||||
[[rsl_mdcx_msg_nack]]
|
||||
==== Modify Connection (MDCX) NACK
|
||||
|
||||
This message is sent by the BTS to the BSC in order to signal the
|
||||
unsuccessful outcome of modifying the user-plane RTP connection for the
|
||||
specified Channel number. It is sent in response to the *Modify
|
||||
Connection (MDCX)*.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Cause | 08.58 9.3.26 | M | TLV | >= 3
|
||||
|===
|
||||
|
||||
[[rsl_dlcx_ind_msg]]
|
||||
==== Delete Connection (DLCX) Indication
|
||||
|
||||
This message is sent by the BTS in order to indicate the automatic
|
||||
deletion of a BTS-local UDP connection for user-plane RTP traffic at the
|
||||
time of RF Channel release.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | M | TV | 3
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_STAT>> | M | TV | 3
|
||||
| Cause | 08.58 9.3.26 | M | TLV | >= 3
|
||||
|===
|
||||
|
||||
[[rsl_dlcx_msg]]
|
||||
==== Delete Connection (DLCX)
|
||||
|
||||
This message is sent by the BSC to the BTS in order to request the
|
||||
disconnection of a user-plane RTP connection for the specified Channel
|
||||
number.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | O | TV | 3
|
||||
|===
|
||||
|
||||
[[rsl_dlcx_msg_ack]]
|
||||
==== Delete Connection (DLCX) ACK
|
||||
|
||||
This message is sent by the BTS in order to signal the successful
|
||||
outcome of deleting the user-plane RTP connection for the specified
|
||||
Channel number. It is sent in response to the *Delete Connection
|
||||
(DLCX)*.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | O | TV | 3
|
||||
| Connection Statistics | <<RSL_IE_IPAC_CONN_STAT>> | C | TV | 29
|
||||
|===
|
||||
|
||||
[[rsl_dlcx_msg_nack]]
|
||||
==== Delete Connection (DLCX) NACK
|
||||
|
||||
This message is sent by the BTS in order to signal the unsuccessful
|
||||
outcome of deleting the user-plane RTP connection for the specified
|
||||
Channel number. It is sent in response to the *Delete Connection
|
||||
(DLCX)*.
|
||||
|
||||
[options="header"]
|
||||
[cols="30%,25%,15%,15%,15%"]
|
||||
|===
|
||||
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
||||
| Message discriminator | 08.58 9.1 | M | V | 1
|
||||
| Message type | <<own_msg_types>> | M | V | 1
|
||||
| Channel number | 08.58 9.3.1 | M | TV | 2
|
||||
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | O | TV | 3
|
||||
| Cause | 08.58 9.3.26 | M | TLV | >= 3
|
||||
|===
|
||||
|
||||
|
||||
=== Information Element Codings
|
||||
|
||||
[[own_msg_types]]
|
||||
==== A-bis/IP specific RSL Message discriminators
|
||||
|
||||
The following message descriminators are used in addition to those
|
||||
indicated in 3GPP TS 08.58 Section 9.1:
|
||||
|
||||
.OsmoBTS specific new message discriminators
|
||||
[options="header",cols="10%,50%,40%"]
|
||||
|===
|
||||
| Message Type | Message | This document §
|
||||
| 0x70 | Create Connection (CRCX) | <<rsl_crcx_msg>>
|
||||
| 0x71 | Create Connection (CRCX) ACK | <<rsl_crcx_msg_ack>>
|
||||
| 0x72 | Create Connection (CRCX) NACK | <<rsl_crcx_msg_nack>>
|
||||
| 0x73 | Modify Connection (MDCX) | <<rsl_mdcx_msg>>
|
||||
| 0x74 | Modify Connection (MDCX) ACK | <<rsl_mdcx_msg_ack>>
|
||||
| 0x75 | Modify Connection (MDCX) NACK | <<rsl_mdcx_msg_nack>>
|
||||
| 0x76 | Delete Connection (DLCX) Indication | <<rsl_dlcx_ind_msg>>
|
||||
| 0x77 | Delete Connection (DLCX) | <<rsl_dlcx_msg>>
|
||||
| 0x78 | Delete Connection (DLCX) ACK | <<rsl_dlcx_msg_ack>>
|
||||
| 0x79 | Delete Connection (DLCX) NACK | <<rsl_dlcx_msg_nack>>
|
||||
|===
|
||||
|
||||
==== A-bis/IP specific RSL IEIs
|
||||
|
||||
The following Information Element Identifiers (IEIs) are used in
|
||||
addition to those indicated in 3GPP TS 08.58 Section 9.3.1:
|
||||
|
||||
.A-bis/IP specific information elements
|
||||
[options="header",cols="10%,50%,40%"]
|
||||
|===
|
||||
| IEI | Name | This document §
|
||||
| 0xf0 | RSL_IE_IPAC_REMOTE_IP | <<RSL_IE_IPAC_REMOTE_IP>>
|
||||
| 0xf1 | RSL_IE_IPAC_REMOTE_PORT | <<RSL_IE_IPAC_REMOTE_PORT>>
|
||||
| 0xf3 | RSL_IE_IPAC_LOCAL_PORT | <<RSL_IE_IPAC_LOCAL_PORT>>
|
||||
| 0xf4 | RSL_IE_IPAC_SPEECH_MODE | <<RSL_IE_IPAC_SPEECH_MODE>>
|
||||
| 0xf5 | RSL_IE_IPAC_LOCAL_IP | <<RSL_IE_IPAC_LOCAL_IP>>
|
||||
| 0xf6 | RSL_IE_IPAC_CONN_STAT | <<RSL_IE_IPAC_CONN_STAT>>
|
||||
| 0xf8 | RSL_IE_IPAC_CONN_ID | <<RSL_IE_IPAC_CONN_ID>>
|
||||
| 0xfc | RSL_IE_IPAC_RTP_PAYLOAD2 | <<RSL_IE_IPAC_RTP_PAYLOAD2>>
|
||||
|===
|
||||
|
||||
[[RSL_IE_IPAC_REMOTE_IP]]
|
||||
==== RSL_IE_IPAC_REMOTE_IP
|
||||
|
||||
This information element contains the remote (MGW side) IPv4 address in
|
||||
network byte order. It is encoded as fixed-size element with one byte
|
||||
IEI followed by four bytes IPv4 address.
|
||||
|
||||
[[RSL_IE_IPAC_REMOTE_PORT]]
|
||||
==== RSL_IE_IPAC_REMOTE_PORT
|
||||
|
||||
This information element contains the remote (MGW side) UDP port in
|
||||
network byte order. It is encoded as fixed-size element with one byte
|
||||
IEI followed by two bytes UDP port number.
|
||||
|
||||
[[RSL_IE_IPAC_LOCAL_PORT]]
|
||||
==== RSL_IE_IPAC_LOCAL_PORT
|
||||
|
||||
This information element contains the local (BTS side) IPv4 address in
|
||||
network byte order. It is encoded as fixed-size element with one byte
|
||||
IEI followed by two bytes UDP port number.
|
||||
|
||||
[[RSL_IE_IPAC_SPEECH_MODE]]
|
||||
==== RSL_IE_IPAC_SPEECH_MODE
|
||||
|
||||
This information element encodes the speech mode. It is set according
|
||||
to the voice codec used on the connection. It is encoded as a fixed-size
|
||||
element of two bytes, with one byte IEI followed by one byte Speech mode
|
||||
indicator.
|
||||
|
||||
.A-bis/IP Speech Mode Indicator Values
|
||||
[options="header",width="40%",cols="20%,80%"]
|
||||
|===
|
||||
| Value | Description
|
||||
| 0x00 | TCH/F with FR codec
|
||||
| 0x01 | TCH/F with EFR codec
|
||||
| 0x02 | TCH/F with AMR codec
|
||||
| 0x03 | TCH/H with HR codec
|
||||
| 0x05 | TCH/H with AMR codec
|
||||
|===
|
||||
|
||||
[[RSL_IE_IPAC_LOCAL_IP]]
|
||||
==== RSL_IE_IPAC_LOCAL_IP
|
||||
|
||||
This information element contains the local (BTS side) IPv4 address in
|
||||
network byte order. It is encoded as fixed-size element with one byte
|
||||
IEI followed by four bytes IPv4 address.
|
||||
|
||||
[[RSL_IE_IPAC_CONN_STAT]]
|
||||
==== RSL_IE_IPAC_CONN_STAT
|
||||
|
||||
This information element contains statistics about the RTP connection.
|
||||
|
||||
It is encoded as 29 bytes, with the first byte as IEI and 28 bytes
|
||||
fixed-length payload encoded as follows:
|
||||
|
||||
.A-bis/IP Connection Statistics
|
||||
[options="header",width="60%",cols="15%,15%,70%"]
|
||||
|===
|
||||
| Offset | Size | Description
|
||||
| 0 | 4 | Total number of RTP packets sent
|
||||
| 4 | 4 | Total number of octets sent
|
||||
| 8 | 4 | Total number of RTP packets received
|
||||
| 12 | 4 | Total number of octets received
|
||||
| 16 | 4 | Total number of lost packets in Rx direction
|
||||
| 20 | 4 | Inter-arrival Jitter
|
||||
| 24 | 4 | Average transmission delay
|
||||
|===
|
||||
|
||||
All the above values are each encoded in network byte order.
|
||||
|
||||
A detailed definition of the individual values is given in RFC 1889.
|
||||
|
||||
[[RSL_IE_IPAC_CONN_ID]]
|
||||
==== RSL_IE_IPAC_CONN_ID
|
||||
|
||||
This IE is a TV with a value length of two bytes. The value is a 16 bit
|
||||
connection ID in network byte order.
|
||||
|
||||
|
||||
[[RSL_IE_IPAC_RTP_PAYLOAD2]]
|
||||
==== RSL_IE_IPAC_RTP_PAYLOAD2
|
||||
|
||||
This information element contains the RTP payload identifier, which is
|
||||
used in the PT (Payload Type) field of the RTP header in subsequent
|
||||
transmissions of the RTP flow.
|
||||
|
||||
=== A-bis RSL Initialization / BTS bring-up
|
||||
|
||||
Upon receiving the 'IPA RSL CONNECT' OML message by the respective
|
||||
'Baseband Transceiver' MO, the BTS proceeds with establishing a separate
|
||||
TCP connection for the given TRX.
|
||||
|
||||
[[rsl-msc-pri]]
|
||||
.A-bis RSL BTS bring-up for primary TRX
|
||||
["mscgen"]
|
||||
----
|
||||
include::rsl-startup-pri.msc[]
|
||||
----
|
||||
|
||||
[[rsl-msc-sec]]
|
||||
.A-bis RSL BTS bring-up for secondary TRXs
|
||||
["mscgen"]
|
||||
----
|
||||
include::rsl-startup-sec.msc[]
|
||||
----
|
||||
|
||||
As can be seen by the differences between <<rsl-msc-pri>> and
|
||||
<<rsl-msc-sec>>, the initialization of the primary and secondary TRX
|
||||
slightly differ. As the secondary TRX has no BCCH, it does not (need
|
||||
to) receive any 'RSL BCCH INFORMATION' messages from the BSC.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
== User-Plane Traffic via RTP
|
||||
|
||||
RTP (Realtime Transfer Protocol) is a protocol for streaming of audio
|
||||
and video streaming data. It is specified by IETF RFC 1889.
|
||||
|
||||
OsmoBTS A-bis/IP implements RTP as transport medium for circuit-switched
|
||||
user-plane traffic, contrary to the E1 sub-slot based transport as
|
||||
specified in 3GPP TS 08.60.
|
||||
|
||||
The RTP transport endpoint parameters are configured using the RSL User
|
||||
Plane Transport Management procedures described in <<user_plane_txp_mgmt>>.
|
||||
|
||||
RTCP is implemented in addition to RTP, on a UDP port number of the RTP
|
||||
port incremented by one.
|
||||
|
||||
=== RTP Payload Formats
|
||||
|
||||
The RTP payload format depends on the voice codec used on the radio
|
||||
channel. The OsmoBTS is simply passing the GSM speech frames between
|
||||
the Um radio interface channels and the RTP payload (and vice-versa).
|
||||
|
||||
No transcoding function is implemented in the BTS!
|
||||
|
||||
.RTP Payload formats
|
||||
[options="header",width="60%",cols="15%,15%,70%"]
|
||||
|===
|
||||
| TCH | Codec | RTP payload format specification
|
||||
| TCH/F | FR | IETF RFC 3551 Section 4.5.8
|
||||
| TCH/F | EFR | IETF RFC 3551 Section 4.5.9
|
||||
| TCH/F | AMR | IETF RFC 4867
|
||||
| TCH/H | HR | IETF RFC 5993
|
||||
| TCH/H | AMR | IETF RFC 4867
|
||||
|===
|
|
@ -0,0 +1,120 @@
|
|||
== OsmoBTS software architecture
|
||||
|
||||
=== OsmoBTS PHY interface abstraction
|
||||
|
||||
The OsmoBTS PHY interface serves as an internal abstraction layer
|
||||
between given PHY hardware (as provided by the bts_model) and the actual
|
||||
logical transceivers (TRXs) of a BTS inside the OsmoBTS code base.
|
||||
|
||||
|
||||
==== PHY link
|
||||
|
||||
A PHY link is a physical connection / link towards a given PHY. This
|
||||
might be, for example,
|
||||
|
||||
* a set of file descriptors to device nodes in the /dev/ directory
|
||||
(sysmobts, litecell15)
|
||||
* a packet socket for sending raw Ethernet frames to an OCTPHY
|
||||
* a set of UDP sockets for interacting with OsmoTRX
|
||||
|
||||
Each PHY interface has a set of attribute/parameters and a list of 1 to
|
||||
n PHY instances.
|
||||
|
||||
PHY links are numbered 0..n globally inside OsmoBTS.
|
||||
|
||||
Each PHY link is configured via the VTY using its individual top-level
|
||||
vty node. Given the different bts-model / phy specific properties, the
|
||||
VTY configuration options (if any) of the PHY instance differ between
|
||||
BTS models.
|
||||
|
||||
The PHY links and instances must be configured above the BTS/TRX nodes
|
||||
in the configuration file. If the file is saved via the VTY, the code
|
||||
automatically ensures this.
|
||||
|
||||
|
||||
==== PHY instance
|
||||
|
||||
A PHY instance is an instance of a PHY, accessed via a PHY link.
|
||||
|
||||
In the case of osmo-bts-sysmo and osmo-bts-trx, there is only one
|
||||
instance in every PHY link. This is due to the fact that the API inside
|
||||
that PHY link does not permit for distinguishing multiple different
|
||||
logical TRXs.
|
||||
|
||||
Other PHY implementations like the OCTPHY however do support addressing
|
||||
multiple PHY instances via a single PHY link.
|
||||
|
||||
PHY instances are numbered 0..n inside each PHY link.
|
||||
|
||||
Each PHY instance is configured via the VTY as a separate node beneath each
|
||||
PHY link. Given the different bts-model / phy specific properties, the
|
||||
VTY configuration options (if any) of the PHY instance differ between
|
||||
BTS models.
|
||||
|
||||
|
||||
==== Mapping PHY instances to TRXs
|
||||
|
||||
Each TRX node in the VTY must use the 'phy N instance M' command in
|
||||
order to specify which PHY instance is allocated to this specific TRX.
|
||||
|
||||
=== Internal control flow
|
||||
|
||||
==== start-up / sequencing during OsmoBTS start
|
||||
|
||||
.Control flow at OsmoBTS start-up procedure
|
||||
[options="header",cols="10%,35%,55%"]
|
||||
|===
|
||||
| section | function | description
|
||||
| bts-specific | main() | Entering main() from glibc
|
||||
| common | bts_main() | initialization of talloc contexts
|
||||
| common | bts_log_init() | initialization of logging
|
||||
| common | handle_options() | common option parsing
|
||||
| bts-specific | bts_model_handle_options() | model-specific option parsing
|
||||
| common | gsm_bts_alloc() | allocation of BTS/TRX/TS data structures
|
||||
| common | vty_init() | Initialziation of VTY core, libosmo-abis and osmo-bts VTY
|
||||
| common | main() | Setting of scheduler RR priority (if configured)
|
||||
| common | main() | Initialization of GSMTAP (if configured)
|
||||
| common | bts_init() | configuration of defaults in bts/trx/s object
|
||||
| bts-specific | bts_model_init | ?
|
||||
| common | abis_init() | Initialization of libosmo-abis
|
||||
| common | vty_read_config_file() | Reading of configuration file
|
||||
| bts-specific | bts_model_phy_link_set_defaults() | Called for every PHY link created
|
||||
| bts-specific | bts_model_phy_instance_set_defaults() | Called for every PHY Instance created
|
||||
| common | bts_controlif_setup() | Initialization of Control Interface
|
||||
| bts-specific | bts_model_ctrl_cmds_install() | Install model-specific control interface commands
|
||||
| common | telnet_init() | Initialization of telnet interface
|
||||
| common | pcu_sock_init() | Initializaiton of PCU socket
|
||||
| common | main() | Installation of signal handlers
|
||||
| common | abis_open() | Start of the A-bis connection to BSC
|
||||
| common | phy_links_open() | Iterate over list of configured PHY links
|
||||
| bts-specific | bts_model_phy_link_open() | Open each of the configured PHY links
|
||||
| common | write_pid_file() | Generate the pid file
|
||||
| common | osmo_daemonize() | Fork as daemon in background (if configured)
|
||||
| common | bts_main() | Run main loop until global variable quit >= 2
|
||||
|===
|
||||
|
||||
|
||||
==== At time of OML establishment
|
||||
|
||||
.Control flow at time of OML establishment
|
||||
[options="header",cols="10%,35%,55%"]
|
||||
|===
|
||||
| section | function | description
|
||||
| bts-specific | bts_model_oml_estab() | Called by core once OML link is established
|
||||
| bts-specific | bts_model_check_oml() | called each time OML sets some attributes on a MO, checks if attributes are valid
|
||||
| bts-specific | bts_model_apply_oml() | called each time OML sets some attributes on a MO, stores attribute contents in data structures
|
||||
| bts-specific | bts_model_opstart() | for NM_OC_BTS, NM_OC_SITE_MANAGER, NM_OC_GPRS_NSE, NM_OC_GPRS_CELL, NMO_OC_GPRS_NSVC
|
||||
| bts-specific | bts_model_opstart() | for NM_OC_RADIO_CARRIER for each trx
|
||||
| bts-specific | bts_model_opstart() | for NM_OC_BASEB_TRANSC for each trx
|
||||
| bts-specific | bts_model_opstart() | for NM_OC_CHANNEL for each timeslot on each trx
|
||||
| bts-specific | bts_model_change_power() | change transmit power for each trx (power ramp-up/ramp-down)
|
||||
|===
|
||||
|
||||
==== At time of RSL connection loss
|
||||
|
||||
.Control flow at time of RSL connection loss
|
||||
[options="header",cols="10%,35%,55%"]
|
||||
|===
|
||||
| section | function | description
|
||||
| bts-specific | bts_model_abis_close() | called when either one of the RSL links or the OML link are down
|
||||
|===
|
|
@ -0,0 +1,405 @@
|
|||
== OsmoBTS hardware support
|
||||
|
||||
OsmoBTS consists of a generic part common to all BTS, and a
|
||||
hardware-specific _common_ part, and a _hardware-specific_ part. The
|
||||
hardware specific part is generally referred to as the _bts_model_ code.
|
||||
|
||||
The common part includes the core BTS architecture as well as code for
|
||||
implementing the external interfaces such Abis, control, PCU socket and
|
||||
GSMTAP.
|
||||
|
||||
The bts_model parts include support for driving one particular
|
||||
implementation of a GSM physical layer (PHY). Such a physical layer
|
||||
implementation can come in many forms. Sometimes it runs on a general
|
||||
purpose CPU, sometimes on a dedicated ARM core, a dedicated DSP, a
|
||||
combination of DSP and FPGA.
|
||||
|
||||
Every PHY implementation offers some kind of primitives by which the PHY
|
||||
can be controlled, and by which the PHY exchanges data with the higher
|
||||
layers of the protocol stack in the OsmoBTS code.
|
||||
|
||||
The PHY-specific primitives are encapsulated in the bts_model code, and
|
||||
offered as a PHY-independent _L1SAP_ interface towards the common part of
|
||||
OsmoBTS.
|
||||
|
||||
In addition, each bts_model implements a set of functions that the
|
||||
common part calls. Those functions are pre-fixed by bts_model_.
|
||||
|
||||
Each bts_model may offer
|
||||
|
||||
* model-specific VTY commands for both configuration and run-time interaction
|
||||
* model-specific command line arguments
|
||||
* model-specific control interface commands
|
||||
|
||||
== `osmo-bts-sysmo` for sysmocom sysmoBTS
|
||||
|
||||
The sysmocom sysmoBTS is a range of GSM BTSs basd around an embedded
|
||||
system implementing the PHY in a combination of DSP+FPGA. The PHY is
|
||||
configured by a set of primitives described by header files. Those
|
||||
primitives are exchanged ove a set of message queues exposed on the
|
||||
Linux-running ARM core via device nodes in `/dev/msgq/`. Internally,
|
||||
the message queues map to shared memory between the Linux-running ARM
|
||||
core and the DSP running the PHY implementation.
|
||||
|
||||
The OsmoBTS bts_model code for the sysmoBTS can be found in the
|
||||
`src/osmo-bts-sysmo` sub-directory of the OsmoBTS code base.
|
||||
|
||||
`osmo-bts-sysmo` has been the primary target platform for
|
||||
OsmoBTS for many years and is thus the most feature-complete and mature
|
||||
platform supported by OsmoBTS at this point.
|
||||
|
||||
The sysmoBTS PHY supports a direct PHY interface to OsmoPCU, reducing
|
||||
the latency and amount of primitives that OsmoBTS would otherwise need
|
||||
to pass through from the PHY message queues to the PCU socket and
|
||||
vice-versa.
|
||||
|
||||
|
||||
=== `osmo-bts-sysmo` specific command line arguments
|
||||
|
||||
*--dsp-trace 'DSPMASK'*::
|
||||
Set the DSP trace flags (a single hexadecimal 32bit value).
|
||||
This has been deprecated by VTY based commands, see
|
||||
<<osmo-bts-sysmo-dsp-trace>> for further information.
|
||||
*--pcu-direct*::
|
||||
Indicate that an external PCU (e.g. OsmoPCU) will directly
|
||||
open the DSP messge queues to the PHY / PH-SAP, and only MPH
|
||||
primitives are passed via OsmoBTS.
|
||||
|
||||
|
||||
=== `osmo-bts-sysmo` specific VTY commands
|
||||
|
||||
For a auto-generated complete syntax reference of the VTY commands,
|
||||
please see the associated _OsmoBTS VTY reference manual_
|
||||
<<vty-ref-osmobts>>. The section
|
||||
below only lists the most important commands.
|
||||
|
||||
==== at the 'SHOW' node
|
||||
|
||||
===== `show trx 0 clock-source`
|
||||
|
||||
Display the currently active clock source configuration for the TRX
|
||||
|
||||
[[osmo-bts-sysmo-dsp-trace]]
|
||||
===== `show trx 0 dsp-trace-flags`
|
||||
|
||||
Show the currently active DSP trace flags for the TRX
|
||||
|
||||
===== `trx 0 dsp-trace-flag`
|
||||
|
||||
Use this command to enable/disable/configure the DSP tracing flags that
|
||||
define what debug messages will appear on `/dev/rtfifo/dsp_trace`.
|
||||
|
||||
==== at the 'ENABLE' node
|
||||
|
||||
===== `trx 0 tx-power <-110-100>`
|
||||
|
||||
Change the current TRX transmit power to the given value in dBm.
|
||||
|
||||
===== `trx 0 rf-clock-info reset`
|
||||
|
||||
Part of the clock calibration procedure:
|
||||
Reset the clock correction value.
|
||||
|
||||
===== `trx 0 rf-clock-info correct`
|
||||
|
||||
Part of the clock calibration procedure:
|
||||
Apply the current measured correction value between the reference clock
|
||||
and the local clock.
|
||||
|
||||
==== at the 'PHY instance' node
|
||||
|
||||
==== `clock-calibration eeprom`
|
||||
|
||||
Obtain clock calibration value from EEPROM.
|
||||
|
||||
==== `clock-calibration default`
|
||||
|
||||
Use hardware default clock calibration value.
|
||||
|
||||
==== `clock-calibration <-4095-4095>`
|
||||
|
||||
Use specified clock calibration value (not EEPROM/default).
|
||||
|
||||
==== `clock-source (tcxo|ocxo|ext|gps)`
|
||||
|
||||
Specify the clock source for the PHY:
|
||||
|
||||
tcxo::
|
||||
Use the TCXO. This is the default on sysmoBTS 2050.
|
||||
ocxo::
|
||||
Use the OCXO (only valid on units equipped with OCXO). This is
|
||||
the default on all sysmoBTS 1002/1020/1100 and SOB-BTS.
|
||||
ext::
|
||||
Use the external clock input.
|
||||
gps::
|
||||
Use the clock derived from GPS. You shouldn't use this clock
|
||||
directly, but rather use the TCXO and regularly re-calibrate
|
||||
against GPS.
|
||||
|
||||
==== `trx-calibration-path PATH`
|
||||
|
||||
Use calibration files from the given 'PATH', rather tan calibration
|
||||
values from the EEPROM.
|
||||
|
||||
=== `osmo-bts-sysmo` specific control interface commands
|
||||
|
||||
==== trx.0.clock-info
|
||||
|
||||
Obtain information on the current clock status:
|
||||
|
||||
----
|
||||
bsc_control.py -d localhost -p 4238 -g trx.0.clock-info
|
||||
Got message: GET_REPLY 1 trx.0.clock-info -100,ocxo,0,0,gps
|
||||
----
|
||||
|
||||
which is to be interpreted as:
|
||||
|
||||
* current clock correction value is -100 ppb
|
||||
* current clock source is OCXO
|
||||
* deviation between clock source and calibration source is 0 ppb
|
||||
* resolution of clock error measurement is 0 ppt (0 means no result yet)
|
||||
* current calibration source is GPS
|
||||
|
||||
When this attribute is set, any value passed on is discarded, but the clock
|
||||
calibration process is re-started.
|
||||
|
||||
==== trx.0.clock-correction
|
||||
|
||||
This attribute can get and set the current clock correction value:
|
||||
|
||||
----
|
||||
bsc_control.py -d localhost -p 4238 -g trx.0.clock-correction
|
||||
Got message: GET_REPLY 1 trx.0.clock-correction -100
|
||||
----
|
||||
|
||||
----
|
||||
bsc_control.py -d localhost -p 4238 -s trx.0.clock-correction -- -99
|
||||
Got message: SET_REPLY 1 trx.0.clock-correction success
|
||||
----
|
||||
|
||||
|
||||
== `osmo-bts-trx` for OsmoTRX
|
||||
|
||||
OsmoTRX is a C-language implementation of the GSM radio modem,
|
||||
originally developed as the 'Transceiver' part of OpenBTS. This radio
|
||||
modem offers an interface based on top of UDP streams.
|
||||
|
||||
The OsmoBTS bts_model code for OsmoTRX is called
|
||||
`osmo-bts-trx`. It implements the UDP stream interface of
|
||||
OsmoTRX, so both parts can be used together to implement a complete GSM
|
||||
BTS based on general-purpose computing SDR.
|
||||
|
||||
As OsmoTRX is general-purpose software running on top of Linux, it is
|
||||
thus not tied to any specific physical hardware. At the time of this
|
||||
writing, OsmoTRX supports a variety of Ettus USRP SDRs via the UHD
|
||||
driver, as well as the Fairwaves UmTRX and derived products.
|
||||
|
||||
OsmoTRX is not a complete GSM PHY but 'just' the radio modem. This
|
||||
means that all of the Layer 1 functionality such as scheduling,
|
||||
convolutional coding, etc. is actually also implemented inside OsmoBTS.
|
||||
|
||||
As such, the boundary between OsmoTRX and `osmo-bts-trx` is at
|
||||
a much lower interface, which is an internal interface of other more
|
||||
traditional GSM PHY implementations.
|
||||
|
||||
Besides OsmoTRX, there are also other implementations (both Free
|
||||
Software and proprietary) that implement the same UDP stream based radio
|
||||
modem interface.
|
||||
|
||||
|
||||
=== `osmo-bts-trx` specific VTY commands
|
||||
|
||||
For a auto-generated complete syntax reference of the VTY commands,
|
||||
pleas see the associated _OsmoBTS VTY reference manual_
|
||||
<<vty-ref-osmobts>>. The section below only lists the most important
|
||||
commands.
|
||||
|
||||
==== at the 'SHOW' node
|
||||
|
||||
===== `show transceivers`
|
||||
|
||||
Display information about configured/connected OsmoTRX transceivers in
|
||||
human-readable format to current VTY session.
|
||||
|
||||
==== at the 'PHY' configuration node
|
||||
|
||||
===== `osmotrx ip HOST`
|
||||
|
||||
Set the IP addess of the OsmoTRX transceiver to which we should connect
|
||||
to.
|
||||
|
||||
===== `osmotrx base-port (local|remote) <0-65535>`
|
||||
|
||||
Configure the base UDP port for the OsmoTRX interface for either the
|
||||
local (OsmoBTS) or remote (OsmoTRX) side of the UDP flows.
|
||||
|
||||
===== `osmotrx fn-advance <0-30>`
|
||||
|
||||
Set the number of frames to be transmitted to transceiver in advance of
|
||||
current GSM frame number.
|
||||
|
||||
===== `osmotrx rts-advance <0-30>`
|
||||
|
||||
Set the number of frames to be requested from PCU in advance of current
|
||||
frame number. Do not change this unless you have a good reason!
|
||||
|
||||
===== `osmotrx rx-gain <0-50>`
|
||||
|
||||
Set the receiver gain (configured in the hardware) in dB.
|
||||
|
||||
===== `osmotrx tx-attenuation <0-50>`
|
||||
|
||||
Set the transmitter attenuation (configured in the hardware) in dB.
|
||||
|
||||
===== `osmotrx tx-attenuation oml`
|
||||
|
||||
Use the Value in the A-bis OML Attribute `MAX_POWER_REDUCTION` as
|
||||
transmitter attenuation.
|
||||
|
||||
==== at the 'PHY Instance' configuration node
|
||||
|
||||
===== `slotmask (1|0) (1|0) (1|0) (1|0) (1|0) (1|0) (1|0) (1|0)`
|
||||
|
||||
Configure which timeslots should be active on this TRX. Normally all
|
||||
timeslots are enabled, unless you are running on a cpu-constrained
|
||||
deeply embedded system.
|
||||
|
||||
===== `osmotrx maxdly <0-31>`
|
||||
|
||||
Set the maximum delay for received symbols (in number of GSM symbols).
|
||||
|
||||
|
||||
== `osmo-bts-octphy` for Octasic OCTPHY-2G
|
||||
|
||||
The Octasic OCTPHY-2G is a GSM PHY implementation inside an Octasic
|
||||
proprietary 24-core DSP called OCTDSP.
|
||||
|
||||
This DSP has a built-in Gigabit Ethernet interface, over which it
|
||||
exchanges PHY-layer primitives in raw Ethernet frames with the upper
|
||||
layers running on another CPU attached to the same Ethernet. Those
|
||||
primitives are described in a set of C-language header files.
|
||||
|
||||
OsmoBTS implements the raw Ethernet frame based primitives as well as
|
||||
the associated transport protocol (OKTPKT/OCTVC1) in the
|
||||
`osmo-btso-octphy` bts_model code.
|
||||
|
||||
You can run the `osmo-bts-octphy` on any system connected to the same
|
||||
Ethernet as the OCTDSP running the OCTPHY. This can be either an
|
||||
embedded ARM or x86 SoM part of the OCTBTS hardware, or it can be any
|
||||
other Linux system attached via an Ethernet switch.
|
||||
|
||||
Each OCTDSP running OCTSDR-2G offers a set of primitives part of a
|
||||
OCTPKT session, which is mapped to an OsmoBTS PHY link. Depending on
|
||||
the OCTSDR-2G software version, you may create multiple software TRX by
|
||||
creating multiple OsmoBTS PHY instances inside that PHY link.
|
||||
|
||||
Multiple DSPs may exsist in one circuit board, then each of the DSPs is
|
||||
interfaced by one OsmoBTS PHY link, and each of them may have one or
|
||||
more OsmoBTS PHY instances creating a Multi-TRX configuration.
|
||||
|
||||
|
||||
== `osmo-bts-litecell15` for Nutaq/Nuran LiteCell 1.5
|
||||
|
||||
The Nutaq/Nuran LiteCell 1.5 implements a dual-transceiver GSM BTS based
|
||||
on a mixed ARM/DSP/FPGA architecture. The PHY layer is implemented on
|
||||
DSP/FPGA and similar to that of the sysmoBTS: It exchanges primitives
|
||||
described in a set of C-language header files over message queues
|
||||
between the ARM and the DSP.
|
||||
|
||||
This interface is implemented in the `osmo-bts-litecell15` bts_model of
|
||||
OsmoBTS. You would run `osmo-bts-litecell15` on the ARM/Linux processor
|
||||
of the Litecell 1.5.
|
||||
|
||||
The two transceivers of the Litecell 1.5 each have their own set of DSP
|
||||
message queues. Each set of message queues is wrapped into one OsmoBTS
|
||||
PHY link, offering one OsmoBTS PHY instance.
|
||||
|
||||
The Litecell 1.5 PHY supports a direct PHY interface to OsmoPCU,
|
||||
reducing the latency and amount of primitives that OsmoBTS would
|
||||
otherwise need to pass through from the PHY message queues to the PCU
|
||||
socket and vice-versa.
|
||||
|
||||
=== `osmo-bts-trx` specific VTY commands
|
||||
|
||||
For a auto-generated complete syntax reference of the VTY commands,
|
||||
please see the associated _OsmoBTS VTY reference manual_
|
||||
<<vty-ref-osmobts>>. The section below only lists the most important
|
||||
commands.
|
||||
|
||||
==== at the 'SHOW' node
|
||||
|
||||
===== `show phy <0-255> system-information`
|
||||
|
||||
Show information about the hardware platform, DSP and OCTPHY-2G software
|
||||
version.
|
||||
|
||||
===== `show phy <0-255> rf-port-stats <0-1>`
|
||||
|
||||
Show information about the RF port interfaces.
|
||||
|
||||
===== `show phy <0-255> clk-sync-stats`
|
||||
|
||||
Show information about the clock synchronization manager.
|
||||
|
||||
==== at the 'PHY' configuration node
|
||||
|
||||
===== `octphy hw-addr HWADDR`
|
||||
|
||||
Specify the Ethernet hardware address (mac address) of the DSP running
|
||||
the OCTPHY-2G software for this PHY link.
|
||||
|
||||
===== `octphy net-device NAME`
|
||||
|
||||
Specify the Ethernet network device (like `eth0`) through which the DSP
|
||||
can be reached from OsmoBTS.
|
||||
|
||||
===== `octphy rf-port-index <0-255>`
|
||||
|
||||
Specify which RF port should be used for this PHY link.
|
||||
|
||||
===== `octphy rx-gain <0-73>`
|
||||
|
||||
Configure the receiver gain in dB.
|
||||
|
||||
===== `octphy tx-attenuation <0-359>`
|
||||
|
||||
Configure the transmitter attenuation in quarter-dB
|
||||
|
||||
|
||||
|
||||
|
||||
== `osmo-bts-virtual` for Virtual Um Interface
|
||||
|
||||
This is a special BTS model used for research, simulation and testing.
|
||||
Rather than communicating over a wireless RF interface, the GSM Um
|
||||
messages are encapsulated over GSMTAP/UDP/IP.
|
||||
|
||||
At the time of writing, this functionality is not fully completed. It
|
||||
is the idea to adopt the OsmocomBB MS-side GSM implementation to
|
||||
interface with this virtual Um interface, so that many instances of
|
||||
virtual MS can connect to some instances of OsmoBTS, testing MS, BTS,
|
||||
BSC and core network functionality.
|
||||
|
||||
=== `osmo-bts-trx` specific VTY commands
|
||||
|
||||
For a auto-generated complete syntax reference of the VTY commands,
|
||||
please see the associated _OsmoBTS VTY reference manual_
|
||||
<<vty-ref-osmobts>>. The section below only lists the most important
|
||||
commands.
|
||||
|
||||
==== at the 'PHY' config node
|
||||
|
||||
===== `virtual-um net-device NETDEV`
|
||||
|
||||
Configure the network device used for sending/receiving the virtual Um
|
||||
interface messages (e.g. `eth0`).
|
||||
|
||||
===== `virtual-um udp-port <0-65535>`
|
||||
|
||||
Configure the UDP port used for sending/receiving the virtual Um
|
||||
interface messages (default: GSMTAP 2775).
|
||||
|
||||
===== `virtual-um multicast-group GROUP`
|
||||
|
||||
Configure the IP multicast group used for sending/receiving the virtual
|
||||
Um interface messages.
|
|
@ -0,0 +1,154 @@
|
|||
== BTS Configuration
|
||||
|
||||
The role of the BTS is to handle the GSM radio interface. When the BTS
|
||||
application is starting, the A-bis OML connection is established towards
|
||||
the BSC. Almost all BTS configuration (such as ARFCN, channel
|
||||
configuration, transmit power, etc.) will be sent from the BSC to the
|
||||
BTS via OML messages. After OML start-up has competed, the BSC will
|
||||
instruct the BTS to establish the RSL connections.
|
||||
|
||||
Given that most configuration is downloaded from the BSC into the BTS at
|
||||
start-up time, only some very basic settings have to be made in the
|
||||
OsmoBTS software.
|
||||
|
||||
|
||||
=== Command Line Options
|
||||
|
||||
Ths OsmoBTS executables (`osmo-bts-sysmo`, `osmo-bts-trx`,
|
||||
`osmo-bts-octphy`, `osmo-bts-litecell15`, ...) share the following
|
||||
generic command line options:
|
||||
|
||||
==== SYNOPSIS
|
||||
*osmo-bts-sysmo* [-h|-V] [-d 'DBGMASK'] [-D] [-c 'CONFIGFILE' ] [-s] [-T] [-e 'LOGLEVEL'] [-r 'PRIO'] [-i 'GSMTAP-IP'] [-t <1-255>]
|
||||
|
||||
==== 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 <<logging>> 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 `osmo-bts.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 <<logging>>
|
||||
for further information.
|
||||
*-T, --timestamp*::
|
||||
Enable time-stamping of log messages to stderr. This has mostly
|
||||
been deprecated by VTY based logging configuration, see
|
||||
<<logging>> for further 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
|
||||
<<logging>> for further information.
|
||||
*-r, --realtime 'PRIO'*::
|
||||
Enable use of the Linux kernel realtime priority scheduler with
|
||||
the specified priority.
|
||||
It is recommended you use this option on low-performance
|
||||
embedded systems or systems that encounter high non-GSM/GPRS
|
||||
load.
|
||||
*-i, --gsmtap-ip 'GSMTAP-IP'*::
|
||||
Specify the destination IP address for GSMTAP messages.
|
||||
*-t, --trx-num <1-255>*::
|
||||
Specify the number of TRX supported by this BTS.
|
||||
|
||||
There may be additional, hardware specific command line options by the
|
||||
different bts_model implementations.
|
||||
|
||||
|
||||
=== Configuration using the VTY
|
||||
|
||||
Most configuration as well as run-time monitoring and system
|
||||
introspection is implemented using a command-line based interface
|
||||
called _VTY_. A full reference syntax of all existing VTY command is
|
||||
available as a separate document.
|
||||
|
||||
See <<vty>> for further information on the VTY.
|
||||
|
||||
|
||||
==== Required BTS/TRX configuration
|
||||
|
||||
There are some settings that have to be configured locally in the
|
||||
sysmoBTS, as they cannot be set remotely from the BSC. Those
|
||||
settings are stored in the OsmoBTS configuration file, which commonly
|
||||
is stored in `/etc/osmocom/osmo-bts.cfg`.
|
||||
|
||||
.Example Minimal configuration file
|
||||
----
|
||||
!
|
||||
! OsmoBTS (0.0.1.100-0455) configuration saved from vty
|
||||
!!
|
||||
!
|
||||
phy 0 <1>
|
||||
instance 0 <2>
|
||||
bts 0 <3>
|
||||
band DCS1800
|
||||
ipa unit-id 1801 0 <4>
|
||||
oml remote-ip 192.168.100.11 <5>
|
||||
trx 0 <6>
|
||||
phy 0 instance 0 <7>
|
||||
----
|
||||
<1> You must configure at least one PHY link by means of the PHY node
|
||||
<2> You must configure at least one PHY instance in the PHY link
|
||||
<3> There is always exactly one BTS (`bts 0`) configured in OsmoBTS
|
||||
<4> The `ipa unit-id` is what is used to identify this BTS to the BSC
|
||||
<6> The OML Remote IP is the IP address of the BSC, to which the BTS shall connect to.
|
||||
<6> There must be at least one trx (`trx 0`) in each BTS
|
||||
<7> Every TRX must be mapped to a specific PHY instance this way
|
||||
|
||||
For a full reference of all available VTY configuration parameters,
|
||||
please refer to the OsmoBTS VTY Reference document.
|
||||
|
||||
[[gsmtap]]
|
||||
==== Configuring GSMTAP tracing
|
||||
|
||||
In addition to being able to obtain pcap protocol traces of the A-bis
|
||||
communication and the text-based logging from the OsmoBTS
|
||||
software, there is also the capability of tracing all communication on
|
||||
the radio interface. To do so, OsmoBTS can encapsulate
|
||||
MAC blocks (23byte messages at the L2-L1 interface) into _GSMTAP_ and send
|
||||
them via UDP/IP. At that point, they can be captured with utilities like
|
||||
*tcpdump* or *tshark* for further analysis by the *wireshark* protocol
|
||||
analyzer.
|
||||
|
||||
In order to activate this feature, you first need to make sure to start
|
||||
OsmoBTS using the `-i` or `--gsmtap-ip` command line option, specifying
|
||||
the destination IP address for the GSMTAP messages. In most cases,
|
||||
using 127.0.0.1 for passing the messages over the loopback (`lo`) device
|
||||
will be sufficient.
|
||||
|
||||
OsmoBTS can selectively trace such messages by their L1 SAPI, for both
|
||||
Rx and Tx. For a complete list of L1 SAPI values, please refer to the
|
||||
_OsmoBTS VTY reference manual_ <<vty-ref-osmobts>>.
|
||||
|
||||
For example, to enable GSMTAP tracing for messages on all SDCCH
|
||||
channels, you can use the gsmtap-sapi sdcch command at the CONFIG TRX
|
||||
node of the OsmoBTS VTY.
|
||||
|
||||
.Example: Enabling GSMTAP for SDCCH
|
||||
----
|
||||
OsmoBTS> enable
|
||||
OsmoBTS# configure terminal
|
||||
OsmoBTS(config)# bts
|
||||
OsmoBTS(bts)# trx 0
|
||||
OsmoBTS(trx)# gsmtap-sapi sdcch
|
||||
OsmoBTS(trx)# write <1>
|
||||
----
|
||||
<1> the `write` command will make the configuration persistent in the
|
||||
configuration file. This is not required if you wish to enable GSMTAP
|
||||
only in the current session of OsmoBTS.
|
||||
|
||||
De-activation can be performed similarly by using the `no gsmtap-sapi
|
||||
sdcch` command at the `trx` node of the OsmoBTS VTY.
|
||||
|
||||
From the moment they are enabled via VTY, GSMTAP messages will be
|
||||
generated and sent in UDP encapsulation to the IANA-registered UDP port
|
||||
for GSMTAP (4729) at the IP address specified in the command line
|
||||
argument.
|
|
@ -0,0 +1,130 @@
|
|||
== OsmoBTS Interfaces
|
||||
|
||||
OsmoBTS offers a set of interfaces to interact with external entities:
|
||||
|
||||
* A-bis/IP interface to talk to the BSC
|
||||
* bts_model specific PHY interface
|
||||
* VTY interface
|
||||
* Osmocom control interface
|
||||
* GSMTAP interface
|
||||
* PCU interface
|
||||
|
||||
|
||||
=== OsmoBTS Abis/IP Interface
|
||||
|
||||
OsmoBTS implements the GSM A-bis interface as described in the relevant
|
||||
3GPP specifications:
|
||||
|
||||
* A-bis RSL according to 3GPP TS 08.58
|
||||
* A-bis OML according to 3GPP TS 12.21
|
||||
|
||||
As the 3GPP specified A-bis only over E1 interfaces and not over IP,
|
||||
significant enhancements and modifications have been performed as opposed
|
||||
to the 3GPP specifications. Nevertheless, the implementation tries to
|
||||
stay as close a possible to the 3GPP specifications.
|
||||
|
||||
Please see the _OsmoBTS Abis Protocol Specification_
|
||||
<<osmobts-abis-spec>> for more information on this subject.
|
||||
|
||||
|
||||
=== bts_model specific PHY interface
|
||||
|
||||
This interface is specific to the bts_model that OsmoBTS was compiled
|
||||
for. It can take any form as required by the respective hardware.
|
||||
|
||||
Please see the PHY documentation of your respective BTS hardware for more
|
||||
details.
|
||||
|
||||
|
||||
=== OsmoBTS VTY Interface
|
||||
|
||||
See <<vty>> for further information.
|
||||
|
||||
|
||||
=== OsmoBTS Control Interface
|
||||
|
||||
The general structure of the Omsocom control interface is described in
|
||||
<<common-control-if>>.
|
||||
|
||||
The number of control interface commands/attributes is currently quite
|
||||
limited and largely depends on the bts_model used.
|
||||
|
||||
==== trx.N.thermal-attenuation
|
||||
|
||||
The idea of this paramter is to attenuate the system output power as part of
|
||||
thermal management. In some cases the PA might be passing a critical level,
|
||||
so an external control process can use this attribute to reduce the system
|
||||
output power.
|
||||
|
||||
Please note that all values in the context of transmit power calculation
|
||||
are integers in milli-dB (1/10000 bel), so the below example is setting
|
||||
the attenuation at 3 dB:
|
||||
|
||||
----
|
||||
bsc_control.py -d localhost -p 4238 -s trx.0.thermal-attenuation 3000
|
||||
Got message: SET_REPLY 1 trx.0.thermal-attenuation 3000
|
||||
----
|
||||
|
||||
----
|
||||
bsc_control.py -d localhost -p 4238 -g trx.0.thermal-attenuation
|
||||
Got message: GET_REPLY 1 trx.0.thermal-attenuation 3000
|
||||
----
|
||||
|
||||
|
||||
|
||||
=== OsmoBTS GSMTAP Interface
|
||||
|
||||
GSMTAP is a standard created by Osmocom to UDP-encapsulate GSM protocol
|
||||
messages normally communicated over non-IP interfaces for the primary
|
||||
purpose of protocol analysis in the wireshark dissector.
|
||||
|
||||
The initial purpose was to encapsulate GSM Um frames including some
|
||||
meta-data like ARFCN and GSM frame number into something that can be
|
||||
parsed and dispatched within the wireshark dissector.
|
||||
|
||||
This interface has since been extended to many other
|
||||
GSM/GPRS/UMTS interfaces and protocols, and even to TETRA and GMR.
|
||||
|
||||
In OsmoBTS, it is possible to export both uplink and downlink Um
|
||||
messages via GSMTAP. There is a set of VTY configuration options to
|
||||
specify for which logical channels of the Um interface GSMTAP messages
|
||||
shall be emitted, and to which destination IP address they shall be
|
||||
sent.
|
||||
|
||||
Using GSMTAP it is possible to place a virtual tap at the air interface
|
||||
between BTS and MS, without going through the trouble of setting up an
|
||||
actual radio receiver at the same frequencies. Also, GSMTAP export is
|
||||
performed before the Um air-interface encryption (A5) is performed, so
|
||||
all frames are always in plain text.
|
||||
|
||||
Please refer to <<gsmtap>> for more information on how to configure and
|
||||
use this interface.
|
||||
|
||||
|
||||
=== OsmoBTS PCU Socket Interface
|
||||
|
||||
In order to assist the provisioning of GPRS services over the same radio
|
||||
interface as circuit-switched GSM, OsmoBTS exposes a Unix domain socket
|
||||
based interface towards OsmoPCU.
|
||||
|
||||
OsmoPCU is the Osmocom implementation of the GPRS Packet Control Unit
|
||||
(PCU), which is co-located with the BTS in the Osmocom implementation.
|
||||
Contrary to that, many classic E1-based implementations of the GSM RAN
|
||||
co-locate the PCU with the BSC. However, the GSM specifications keep
|
||||
the location up to the implementor.
|
||||
|
||||
The PCU socket interface serves the following purposes:
|
||||
|
||||
* to pass PCU relevant configuration from BTS to PCU
|
||||
* to forward paging requests from BTS to PCU
|
||||
* to forward RACH Requests from BTS to PCU
|
||||
|
||||
Depending on your bts_model, the PCU may also be passing actual
|
||||
PH-DATA.request / PH-DATA.indication / PH-RTS.indication primitives for
|
||||
the PDCH. This is considered sub-optimal, and some BTS models offer a
|
||||
direct interface by which the PCU can exchange those primitives directly
|
||||
with the PHY.
|
||||
|
||||
The default PCU socket interface name is `/tmp/pcu_sock`, but this can
|
||||
be overridden by the @pcu-socket@ VTY command in the BTS configuration
|
||||
VTY node.
|
|
@ -0,0 +1,105 @@
|
|||
== Overview
|
||||
|
||||
=== About this manual
|
||||
|
||||
This manual should help you getting started with the OsmoBTS software.
|
||||
It will cover aspects of configuring and running OsmoBTS as well as some
|
||||
introduction about its internal architecture and external interfaces.
|
||||
|
||||
=== About OsmoBTS
|
||||
|
||||
OsmoBTS is an implementation of a GSM BTS (Base Transceiver Station). A
|
||||
BTS serves as the interface between the Um radio interface towards
|
||||
phones and the wired Abis interface towards the BSC (Base Station
|
||||
Controller). It also implements the network side of the Layer 2 of the
|
||||
Um radio interface: The LAPDm protocol.
|
||||
|
||||
OsmoBTS is licensed as Free and Open Source Software (FOSS) under _GNU
|
||||
AGPLv3_ <<gnu-agplv3>>. It is developed as one GSM network
|
||||
infrastructure component part of the overall Osmocom project.
|
||||
|
||||
As perhaps the first implementation of a GSM BTS ever in the industry,
|
||||
OsmoBTS is implemented in a vendor-independent way and supports a large
|
||||
variety of transceiver hardware and physical layer implementations from
|
||||
many vendors.
|
||||
|
||||
=== Credits
|
||||
|
||||
OsmoBTS was originally developed in 2011 by Andreas Eversberg and Harald
|
||||
Welte. It has since been maintained by Harald Welte and Holger Freyther
|
||||
at sysmocom.
|
||||
|
||||
=== OsmoBTS in the Osmocom GSM network architecture
|
||||
|
||||
OsmoBTS can be used in combination with the various other GSM network
|
||||
elements developed under the umbrella of the Osmocom project.
|
||||
|
||||
Typical configurations either use OsmoBTS with OsmoBSC, or with
|
||||
OsmoNITB, as can be seen in the following figures.
|
||||
|
||||
[[fig-gsm-classic]]
|
||||
.Classic GSM archtiecture using OsmoBTS with OsmoBTS components
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir=LR;
|
||||
MS0 [label="MS"]
|
||||
MS1 [label="MS"]
|
||||
MS2 [label="MS"]
|
||||
MS3 [label="MS"]
|
||||
BTS0 [label="OsmoBTS"]
|
||||
BTS1 [label="OsmoBTS"]
|
||||
BSC [label="OsmoBSC"]
|
||||
MSC [label="MSC/VLR"]
|
||||
HLR [label="HLR/AUC"]
|
||||
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 architecture using OsmoBTS + OsmoNITB
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir=LR;
|
||||
MS0 [label="MS"]
|
||||
MS1 [label="MS"]
|
||||
MS2 [label="MS"]
|
||||
MS3 [label="MS"]
|
||||
BTS0 [label="OsmoBTS"]
|
||||
BTS1 [label="OsmoBTS"]
|
||||
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"]
|
||||
HLR [label="HLR/AUC"]
|
||||
BSC->MSC [label="A"]
|
||||
MSC->HLR [label="C"]
|
||||
MSC->EIR [label="F"]
|
||||
MSC->SMSC;
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
If intended by the user, it is of course also possible to implement an
|
||||
OsmoBTS-compatible Abis-over-IP interface in any third party BSC. The
|
||||
Abis/IP interface and its protocol are documented in the _OsmoBTS
|
||||
Abis Protocol Specification_ <<osmobts-abis-spec>>. However, be advised
|
||||
that such a configuration is currently not officially supported by
|
||||
Osmocom.
|
|
@ -0,0 +1,68 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1</revnumber>
|
||||
<date>December 2015</date>
|
||||
<authorinitials>NJH, HW</authorinitials>
|
||||
<revremark>
|
||||
Initial version, reflecting OsmoBTS master branch as on 2015-Dec-7
|
||||
(commit e28a20a2d9d049cd6312e218a7646593bbc43431).
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2</revnumber>
|
||||
<date>February 2016</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Updated version with Message Sequence Chart of OML and RSL bring-up.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.1</revnumber>
|
||||
<date>February 2016</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Fix A-bis OML/RSL port number swap in message seqeuence charts.
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Neels</firstname>
|
||||
<surname>Hofmayr</surname>
|
||||
<email>nhofmayr@sysmocom.de</email>
|
||||
<authorinitials>NJH</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Senior Software Developer</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Harald</firstname>
|
||||
<surname>Welte</surname>
|
||||
<email>hwelte@sysmocom.de</email>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2015-2016</year>
|
||||
<holder>sysmocom - s.f.m.c. GmbH</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
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 no Invariant Sections, no Front-Cover Texts,
|
||||
and no Back-Cover Texts. A copy of the license is included in
|
||||
the section entitled "GNU Free Documentation License".
|
||||
</para>
|
||||
</legalnotice>
|
|
@ -0,0 +1,90 @@
|
|||
OsmoBTS Abis Protocol Specification
|
||||
===================================
|
||||
Neels Hofmeyr <nhofmeyr@sysmocom.de>
|
||||
|
||||
== Introduction
|
||||
|
||||
This document describes the A-bis interface of *OsmoBTS*. Based on 3GPP TS
|
||||
12.21 and 08.58, this document indicates which of the 3GPP specified A-bis
|
||||
messages and IEs are implemented according to 3GPP specifications, which of
|
||||
these are not or not fully implemented, as well as OsmoBTS-specific extensions
|
||||
to the A-bis interface not specified by 3GPP.
|
||||
|
||||
Extensions to the A-bis interface specific to OsmoBTS are detailed in this
|
||||
document. For details on the messages and IEs that comply with abovementioned
|
||||
3GPP specifications, please refer to those documents.
|
||||
|
||||
.3GPP document versions referred to by this document
|
||||
[cols="20%,80%"]
|
||||
|===
|
||||
|3GPP TS 08.56 | version 8.0.1 Release 1999
|
||||
|3GPP TS 08.58 | version 8.6.0 Release 1999
|
||||
|3GPP TS 08.60 | version 8.2.1 Release 1999
|
||||
|3GPP TS 12.21 | version 8.0.0 Release 1999
|
||||
|===
|
||||
|
||||
.IETF documents referred to by his document
|
||||
[cols="20%,80%"]
|
||||
|===
|
||||
|IETF RFC 768 | User Datagram Protocol
|
||||
|IETF RFC 791 | Internet Protocol
|
||||
|IETF RFC 793 | Transmission Control Protocol
|
||||
|IETF RFC 1889 | RTP: A Transport Protocol for Real-Time Applications
|
||||
|IETF RFC 3551 | RTP Profle for Audio and Video Conferences with Minimal Control
|
||||
|IETF RFC 4867 | RTP Payload Format and Files Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
|
||||
|IETF RFC 5993 | RTP Payload Format for Global Systems for Mobile Communications Half Rate (GSM-HR)
|
||||
|===
|
||||
|
||||
== Overview
|
||||
|
||||
The OsmoBTS A-bis interface consists of traffic management messages (RSL, Radio
|
||||
Signalling Link) and network management messages (OML, Operation & Maintenance
|
||||
Link), encapsulated in an IPA multiplex.
|
||||
|
||||
OML and RSL each use a separate TCP connection.
|
||||
|
||||
.TCP port numbers used by OsmoBTS Abis/IP
|
||||
[options="header",width="50%",cols="35%,65%"]
|
||||
|===
|
||||
|TCP Port Number|Usage
|
||||
|3002|A-bis OML (inside IPA multiplex)
|
||||
|3003|A-bis RSL (inside IPA multiplex)
|
||||
|===
|
||||
|
||||
Both TCP connections for OML and RSL are established in the BTS -> BSC
|
||||
direction, i.e. the BTS is running as a TCP client, while the BSC is
|
||||
running as a TCP server.
|
||||
|
||||
The BTS first establishes the TCP connection for OML. Via OML, the BSC
|
||||
instructs the BTS to which IP address the RSL connection shall be
|
||||
established.
|
||||
|
||||
.Overview of A-bis connection establishment
|
||||
["mscgen"]
|
||||
----
|
||||
include::abis/abis-startup.msc[]
|
||||
----
|
||||
|
||||
=== Identities
|
||||
|
||||
The BTS is locally configured (via administrative means, out of band of
|
||||
this specification) to have a Unit ID. The Unit ID consists of three
|
||||
parts:
|
||||
|
||||
* The Site Number
|
||||
* The BTS number at the site
|
||||
* The TRX number within the BTS
|
||||
|
||||
include::abis/ipa.adoc[]
|
||||
|
||||
include::abis/oml.adoc[]
|
||||
|
||||
include::abis/rsl.adoc[]
|
||||
|
||||
include::abis/rtp.adoc[]
|
||||
|
||||
include::../common/chapters/port_numbers.adoc[]
|
||||
|
||||
include::../common/chapters/glossary.adoc[]
|
||||
|
||||
include::../common/chapters/gfdl.adoc[]
|
|
@ -0,0 +1,42 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1</revnumber>
|
||||
<date>January 2016</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Initial version, reflecting OsmoBTS master branch as on FIXME
|
||||
(commit FIXME).
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Harald</firstname>
|
||||
<surname>Welte</surname>
|
||||
<email>hwelte@sysmocom.de</email>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2016</year>
|
||||
<holder>sysmocom - s.f.m.c. GmbH</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
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".
|
||||
</para>
|
||||
</legalnotice>
|
|
@ -0,0 +1,32 @@
|
|||
OsmoBTS User Manual
|
||||
===================
|
||||
Harald Welte <hwelte@sysmocom.de>
|
||||
|
||||
include::../common/chapters/preface.adoc[]
|
||||
|
||||
include::chapters/overview.adoc[]
|
||||
|
||||
include::chapters/abis.adoc[]
|
||||
|
||||
include::chapters/interfaces.adoc[]
|
||||
|
||||
include::../common/chapters/vty.adoc[]
|
||||
|
||||
include::../common/chapters/logging.adoc[]
|
||||
|
||||
include::chapters/configuration.adoc[]
|
||||
|
||||
include::chapters/bts-models.adoc[]
|
||||
|
||||
include::chapters/architecture.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[]
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/
|
||||
# Makefile from BitBake/OpenEmbedded manuals
|
||||
|
||||
EXTRA_DEPS = gen-mgcp-vty-docbook
|
||||
|
||||
topdir = .
|
||||
mgcp_reference = $(topdir)/osmomgcp-vty-reference.xml
|
||||
manuals = $(mgcp_reference)
|
||||
# types = pdf txt rtf ps xhtml html man tex texi dvi
|
||||
# types = pdf txt
|
||||
types = $(docbooktotypes)
|
||||
docbooktotypes = pdf
|
||||
# htmlcssfile =
|
||||
# htmlcss =
|
||||
|
||||
include ../build/Makefile.inc
|
||||
|
||||
clean:
|
||||
rm -rf $(cleanfiles)
|
||||
|
||||
gen-mgcp-vty-docbook: FORCE
|
||||
$(call command,xsltproc -o generated/combined1.xml \
|
||||
--stringparam with $(PWD)/../common/vty_additions.xml \
|
||||
$(MERGE_DOC) vty/mgcp_vty_reference.xml, \
|
||||
XSLTPROC,Merging Common VTY)
|
||||
$(call command,xsltproc -o generated/combined2.xml \
|
||||
--stringparam with $(PWD)/vty/mgcp_vty_additions.xml \
|
||||
$(MERGE_DOC) generated/combined1.xml, \
|
||||
XSLTPROC,Merging MGCP VTY)
|
||||
$(call command,xsltproc ../vty_reference.xsl generated/combined2.xml > generated/docbook_vty.xml, \
|
||||
XSLTPROC,Converting MGCP VTY to DocBook)
|
|
@ -0,0 +1,44 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!--
|
||||
ex:ts=2:sw=42sts=2:et
|
||||
-*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
||||
-->
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
|
||||
"http://www.docbook.org/xml/5.0/dtd/docbook.dtd" [
|
||||
<!ENTITY chapter-vty SYSTEM "../common/chapters/vty.xml" >
|
||||
<!ENTITY sections-vty SYSTEM "generated/docbook_vty.xml" >
|
||||
]>
|
||||
|
||||
<book>
|
||||
<info>
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1</revnumber>
|
||||
<date>13th August 2012</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Initial</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v2</revnumber>
|
||||
<date>5th March 2014</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Update to match osmo-bsc version 0.13.0-305</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<title>OsmoMGCP VTY Reference</title>
|
||||
|
||||
<copyright>
|
||||
<year>2012-2014</year>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>This work is copyright by <orgname>sysmocom - s.f.m.c. GmbH</orgname>. All rights reserved.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</info>
|
||||
|
||||
<!-- Main chapters-->
|
||||
&chapter-vty;
|
||||
</book>
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='19'>
|
||||
<child_of nodeid='4' />
|
||||
<name>MGCP Global Commands</name>
|
||||
<description>This node allows to configure global MGCP settings. These include
|
||||
the various port numbers.</description>
|
||||
</node>
|
||||
<node id='27'>
|
||||
<child_of nodeid='19' />
|
||||
<name>MGCP Trunk Command</name>
|
||||
<description>This node allows to configure a MGCP trunk. These include the number,
|
||||
the local binding ports, SDP configuration.</description>
|
||||
</node>
|
||||
</vtydoc>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,31 @@
|
|||
# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/
|
||||
# Makefile from BitBake/OpenEmbedded manuals
|
||||
|
||||
EXTRA_DEPS = gen-nat-vty-docbook
|
||||
|
||||
topdir = .
|
||||
nat_reference = $(topdir)/osmonat-vty-reference.xml
|
||||
manuals = $(nat_reference)
|
||||
# types = pdf txt rtf ps xhtml html man tex texi dvi
|
||||
# types = pdf txt
|
||||
types = $(docbooktotypes)
|
||||
docbooktotypes = pdf
|
||||
# htmlcssfile =
|
||||
# htmlcss =
|
||||
|
||||
include ../build/Makefile.inc
|
||||
|
||||
clean:
|
||||
rm -rf $(cleanfiles)
|
||||
|
||||
gen-nat-vty-docbook: FORCE
|
||||
$(call command,xsltproc -o generated/combined1.xml \
|
||||
--stringparam with $(PWD)/../common/vty_additions.xml \
|
||||
$(MERGE_DOC) vty/nat_vty_reference.xml, \
|
||||
XSLTPROC,Merging Common VTY)
|
||||
$(call command,xsltproc -o generated/combined2.xml \
|
||||
--stringparam with $(PWD)/vty/nat_vty_additions.xml \
|
||||
$(MERGE_DOC) generated/combined1.xml, \
|
||||
XSLTPROC,Merging NAT VTY)
|
||||
$(call command,xsltproc ../vty_reference.xsl generated/combined2.xml > generated/docbook_vty.xml, \
|
||||
XSLTPROC,Converting NAT VTY to DocBook)
|
|
@ -0,0 +1,44 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!--
|
||||
ex:ts=2:sw=42sts=2:et
|
||||
-*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
||||
-->
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
|
||||
"http://www.docbook.org/xml/5.0/dtd/docbook.dtd" [
|
||||
<!ENTITY chapter-vty SYSTEM "../common/chapters/vty.xml" >
|
||||
<!ENTITY sections-vty SYSTEM "generated/docbook_vty.xml" >
|
||||
]>
|
||||
|
||||
<book>
|
||||
<info>
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1</revnumber>
|
||||
<date>13th August 2012</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Initial</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v2</revnumber>
|
||||
<date>5th March 2014</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Update to match osmo-bsc version 0.13.0-305</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<title>OsmoNAT VTY Reference</title>
|
||||
|
||||
<copyright>
|
||||
<year>2012-2014</year>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>This work is copyright by <orgname>sysmocom - s.f.m.c. GmbH</orgname>. All rights reserved.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</info>
|
||||
|
||||
<!-- Main chapters-->
|
||||
&chapter-vty;
|
||||
</book>
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='19'>
|
||||
<child_of nodeid='4' />
|
||||
<name>MGCP Commands</name>
|
||||
<description>This node allows to configure global MGCP settings. These include
|
||||
the various port numbers.</description>
|
||||
</node>
|
||||
|
||||
<node id='23'>
|
||||
<child_of nodeid='4' />
|
||||
<name>NAT Commands</name>
|
||||
<description>This node allows to configure the global NAT settings. These include
|
||||
the destination address of the MSC, the filter and rewriting rules to use.</description>
|
||||
</node>
|
||||
<node id='24'>
|
||||
<child_of nodeid='23' />
|
||||
<name>BSC Commands</name>
|
||||
<description>This node allows to configure a BSC. A BSC has a list of
|
||||
LACs, an access token associated to it.</description>
|
||||
</node>
|
||||
<node id='27'>
|
||||
<hide />
|
||||
</node>
|
||||
<node id='28'>
|
||||
<child_of nodeid='23' />
|
||||
<name>Paging Group Commands</name>
|
||||
<description>This node allows to configure a Paging Group. A Paging Group
|
||||
holds the LACs of several destinations and a BSC can refer to a Paging
|
||||
Group. This way several BSCs can receive the paging for a shared LAC.
|
||||
</description>
|
||||
</node>
|
||||
</vtydoc>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,41 @@
|
|||
# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/
|
||||
# Makefile from BitBake/OpenEmbedded manuals
|
||||
|
||||
EXTRA_DEPS = gen-nitb-vty-docbook
|
||||
|
||||
topdir = .
|
||||
nitb_reference = $(topdir)/osmonitb-vty-reference.xml
|
||||
manuals = $(nitb_reference)
|
||||
# types = pdf txt rtf ps xhtml html man tex texi dvi
|
||||
# types = pdf txt
|
||||
types = $(docbooktotypes)
|
||||
docbooktotypes = pdf
|
||||
# htmlcssfile =
|
||||
# htmlcss =
|
||||
|
||||
TOPDIR := ..
|
||||
ASCIIDOCS := osmonitb-usermanual
|
||||
|
||||
include $(TOPDIR)/build/Makefile.asciidoc.inc
|
||||
include $(TOPDIR)/build/Makefile.inc
|
||||
|
||||
osmonitb-usermanual.pdf: chapters/*.adoc
|
||||
|
||||
clean:
|
||||
rm -rf $(cleanfiles)
|
||||
|
||||
gen-nitb-vty-docbook: FORCE
|
||||
$(call command,xsltproc -o generated/combined1.xml \
|
||||
--stringparam with $(PWD)/../common/vty_additions.xml \
|
||||
$(MERGE_DOC) vty/nitb_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/nitb_vty_additions.xml \
|
||||
$(MERGE_DOC) generated/combined2.xml, \
|
||||
XSLTPROC,Merging NITB VTY)
|
||||
$(call command,xsltproc ../vty_reference.xsl generated/combined3.xml > generated/docbook_vty.xml, \
|
||||
XSLTPROC,Converting NITB VTY to DocBook)
|
|
@ -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.
|
||||
====
|
|
@ -0,0 +1,244 @@
|
|||
[[hlr]]
|
||||
== OsmoNITB HLR subsystem
|
||||
|
||||
|
||||
As OsmoNITB is a fully autonomous system, it also includes a
|
||||
minimal/simplistic HLR and AUC. Compared to real GSM networks, it does
|
||||
not implement any of the external interfaces of a real HLR, such as the
|
||||
MAP/TCAP/SCCP protocol. It can only be used inside the OsmoNITB.
|
||||
|
||||
While functionally maintaining the subscriber database and
|
||||
authentication keys, it offers a much reduced feature set. For example,
|
||||
it is not possible to configure bearer service permission lists, or
|
||||
BAOC.
|
||||
|
||||
At this time, the only supported database back end for the OsmoNITB
|
||||
internal HLR/AUC is the file-based SQL database SQLite3.
|
||||
|
||||
|
||||
=== Authorization Policy
|
||||
|
||||
Authorization determines how subscribers can access your network. This
|
||||
is unrelated to authentication, which verifies the authenticity of SIM
|
||||
cards that register with the network.
|
||||
|
||||
OsmoNITB supports three different authorization policies:
|
||||
|
||||
closed::
|
||||
This mode requires subscribers to have a record with their IMSI
|
||||
in the HLR, and it requires that their status is set to
|
||||
`authorized 1`
|
||||
+
|
||||
This reflects the most typical operation of GSM networks, where
|
||||
subscribers have to obtain a SIM card issued by the operator. At the
|
||||
time the SIM gets issued, it is provisioned in the HLR to enable the
|
||||
subscriber to use the services of the network.
|
||||
|
||||
accept-all::
|
||||
This policy accepts any and all subscribers that every try to
|
||||
register to the network. Non-existent subscribers are
|
||||
automatically and dynamically created in the HLR, and they
|
||||
immediately have full access to the network. Any IMSI can
|
||||
register, no matter what SIM card they are using in their
|
||||
phones.
|
||||
+
|
||||
This mode is mostly useful for lab testing or for demonstrating
|
||||
the lack of mutual authentication and the resulting security
|
||||
problems in the GSM system.
|
||||
|
||||
NOTE: As you do not know the Ki of dynamically created subscribers with
|
||||
SIM cards of unknown origin, you cannot use cryptographic authentication
|
||||
and/or encryption!
|
||||
|
||||
CAUTION: Never run a network in accept-all mode, unless you know exactly
|
||||
what you are doing. You are very likely causing service interruption to
|
||||
mobile phones in the coverage area of your BTSs, which is punishable
|
||||
under criminal law in most countries!
|
||||
|
||||
token::
|
||||
This method was created for special-purpose configurations at
|
||||
certain events. It tries to combine the benefits of automatic
|
||||
enrollment with foreign IMSI while trying to prevent causing disruption
|
||||
to phones that register to the network by accident.
|
||||
+
|
||||
This policy is currently not actively supported.
|
||||
|
||||
The currently active policy can be selected using the
|
||||
`auth policy (closed|accept-all|token)` at the `network` configuration
|
||||
node of the VTY.
|
||||
|
||||
=== Location Update Reject Cause
|
||||
|
||||
When a 'Location Update Request' is to be rejected by the network (e.g.
|
||||
due to an unknown or unauthorized subscriber), the 'Location Update
|
||||
Reject' message will contain a 'Reject Cause'.
|
||||
|
||||
You can configure the numeric value of that cause by means of the
|
||||
`location updating reject cause <2-111>` command at the network node.
|
||||
|
||||
|
||||
=== Querying information about a subscriber
|
||||
|
||||
Information about a specific subscriber can be obtained from the HLR by
|
||||
issuing `show subscriber` command.
|
||||
|
||||
For example, to display information about a subscriber with the IMSI
|
||||
602022080345046, you can use the following command:
|
||||
|
||||
.Displaying information about a subscriber
|
||||
----
|
||||
OpenBSC> show subscriber imsi 602022080345046
|
||||
ID: 1, Authorized: 1 <1>
|
||||
Name: 'Frank'
|
||||
Extension: 2342 <2>
|
||||
LAC: 1/0x1 <3>
|
||||
IMSI: 602022080345046
|
||||
TMSI: 4DB8B4D8
|
||||
Pending: 0
|
||||
Use count: 1
|
||||
----
|
||||
|
||||
<1> Whether or not the subscriber is authorized for access
|
||||
<2> OsmoNITB is often treated like a PBX, this is why phone numbers are called extensions
|
||||
<3> The Location Area Code (LAC) indicates where in the network the
|
||||
subscriber has last performed a LOCATION UPDATE. Detached subscribers
|
||||
indicate a LAC of 0.
|
||||
|
||||
Subscribers don't have to be identified/referenced by their IMSI, but
|
||||
they can also be identified by their extension (phone number), their
|
||||
TMSI as well as their internal database ID. Example alternatives
|
||||
showing the same subscriber record are:
|
||||
----
|
||||
OpenBSC> show subscriber id 1
|
||||
----
|
||||
|
||||
or
|
||||
|
||||
----
|
||||
OpenBSC> show subscriber extension 2342
|
||||
----
|
||||
|
||||
|
||||
=== Enrolling a subscriber
|
||||
|
||||
A subscriber can be added to the network in different ways:
|
||||
|
||||
* direct insert into SQL database by external program
|
||||
* semi-automatic from the VTY
|
||||
|
||||
In most applications, the subscribers will be pre-provisioned by direct
|
||||
insertion into the SQL database. This can be done by a custom program,
|
||||
the SQL schema is visible from the `.schema` command on the sqlite3
|
||||
command-line program, and there are several scripts included in the
|
||||
OpenBSC source code, written in both Python as well as Perl language.
|
||||
|
||||
In case you are obtaining pre-provisioned SIM cards from sysmocom: They
|
||||
will ship with a HLR SQL database containing the subscriber records.
|
||||
|
||||
If you prefer to program the SIM cards yourself, you can use the pySim
|
||||
tool available from http://cgit.osmocom.org/cgit/pysim/. It has the
|
||||
ability to append the newly-provisioned SIM cards to an existing HLR
|
||||
database, please check its `--write-hlr` command line argument.
|
||||
|
||||
|
||||
NOTE: OsmoNITB will automatically add new subscriber records for every
|
||||
IMSI that ever tries to perform a LOCATION UPDATE with the network.
|
||||
However, those subscriber records are marked as "not authorized", i.e.
|
||||
they will not be able to use your network.
|
||||
|
||||
|
||||
=== Changing subscriber properties
|
||||
|
||||
|
||||
Once a subscriber exists in the HLR, his properties can be set
|
||||
interactively from the VTY. Modifying subscriber properties requires
|
||||
the VTY to be in the privileged (`enable`) mode.
|
||||
|
||||
All commands are single-line commands and always start with identifying
|
||||
the subscriber on which the operation shall be performed. Such
|
||||
identification can be performed by
|
||||
|
||||
* IMSI
|
||||
* TMSI
|
||||
* extension number
|
||||
* ID (internal identifier)
|
||||
|
||||
|
||||
==== Changing the subscriber phone number
|
||||
|
||||
|
||||
You can set the phone number of the subscriber with IMSI 602022080345046
|
||||
to 12345 by issuing the following VTY command from the enable node:
|
||||
|
||||
.Changing the phone number of a subscriber
|
||||
----
|
||||
OpenBSC# subscriber imsi 602022080345046 extension 12345
|
||||
----
|
||||
|
||||
|
||||
==== Changing the subscriber name
|
||||
|
||||
The subscriber name is an internal property of OsmoNITB. The name will
|
||||
never be transmitted over the air interface or used by the GSM protocol.
|
||||
The sole purpose of the name is to make log output more intuitive, as
|
||||
human readers of log files tend to remember names easier than IMSIs or
|
||||
phone numbers.
|
||||
|
||||
In order to set the name of subscriber with extension number 12345 to
|
||||
"Frank", you can issue the following command on the VTY enable node:
|
||||
`subscriber extension 12345 name Frank`
|
||||
|
||||
The name may contain spaces and special characters. You can verify the
|
||||
modified subscriber record by issuing the `show subscriber extension
|
||||
12345` command.
|
||||
|
||||
|
||||
==== Changing the authorization status
|
||||
|
||||
As the HLR automatically adds records for all subscribers it sees, those
|
||||
that are actually permitted to use the network have to be authorized by
|
||||
setting the authorized property of the subscriber.
|
||||
|
||||
You can set the authorized property by issuing the following VTY command
|
||||
from the enable node:
|
||||
|
||||
.Authorizing a subscriber
|
||||
----
|
||||
OpenBSC# subscriber extension 12345 authorized 1
|
||||
----
|
||||
|
||||
Similarly, you can remove the authorized status from
|
||||
a subscriber by issuing the following command:
|
||||
|
||||
.Un-authorizing a subscriber
|
||||
----
|
||||
OpenBSC# subscriber extension 12345 authorized 0
|
||||
----
|
||||
|
||||
|
||||
==== Changing the GSM authentication algorithm and Ki
|
||||
|
||||
In order to perform cryptographic authentication of the subscriber, his
|
||||
Ki needs to be known to the HLR/AUC. Furthermore, the authentication
|
||||
algorithm implemented on the SIM card (A3/A8) must match that of the
|
||||
algorithm configured in the HLR.
|
||||
|
||||
Currently, OsmoNITB supports the following authentication algorithms:
|
||||
|
||||
none:: No authentication is performed
|
||||
xor:: Authentication is performed using the XOR algorithm (for test/debugging purpose)
|
||||
comp128v1:: Authentication is performed according to the COMP128v1 algorithm
|
||||
|
||||
WARNING: None of the supported authentication algorithms are
|
||||
cryptographically very strong. Development is proceeding to include
|
||||
support for stronger algorithms like GSM-MILENAGE. Please contact
|
||||
sysmocom if you require strong authentication support.
|
||||
|
||||
In order to configure a subscriber for COMP128v1 and to set his Ki, you
|
||||
can use the following VTY command from the enable node:
|
||||
|
||||
.Configuring a subscriber for COMP128v1 and setting Ki
|
||||
----
|
||||
OpenBSC# subscriber extension 2342 a3a8 comp128v1 000102030405060708090a0b0c0d0e0f
|
||||
----
|
||||
|
|
@ -0,0 +1,206 @@
|
|||
[[mncc]]
|
||||
== MNCC for external Call Control
|
||||
|
||||
The 3GPP GSM specifications define an interface point (service access
|
||||
point) inside the MSC between the call-control part and the rest of the
|
||||
system. This service access point is called the MNCC-SAP. It is
|
||||
described in _3GPP TS 24.007_ <<3gpp-ts-24-007>> Chapter 7.1.
|
||||
|
||||
However, like for all internal interfaces, 3GPP does not give any
|
||||
specific encoding for the primitives passed at this SAP.
|
||||
|
||||
The MNCC protocol of OsmoNITB has been created by the Osmocom community
|
||||
and allows to control the call handling and audio processing by an
|
||||
external application. The interface is currently exposed using Unix
|
||||
Domain Sockets. The protocol is defined in the `mncc.h` header file.
|
||||
|
||||
OsmoNITB can run in two different modes:
|
||||
|
||||
. with internal MNCC handler
|
||||
. with external MNCC handler
|
||||
|
||||
=== Internal MNCC handler
|
||||
|
||||
When the internal MNCC handler is enabled, OsmoNITB will switch voice
|
||||
calls between GSM subscribers internally and automatically based on
|
||||
the subscribers __extension__ number. No external software is required.
|
||||
|
||||
NOTE: Internal MNCC is the default behavior.
|
||||
|
||||
==== Internal MNCC Configuration
|
||||
|
||||
The internal MNCC handler offers some configuration parameters under the
|
||||
`mncc-int` VTY configuration node.
|
||||
|
||||
===== `default-codec tch-f (fr|efr|amr)`
|
||||
|
||||
Using this command, you can configure the default voice codec to be used
|
||||
by voice calls on TCH/F channels.
|
||||
|
||||
===== `default-codec tch-h (hr|amr)`
|
||||
|
||||
Using this command, you can configure the default voice codec to be used
|
||||
by voice calls on TCH/H channels.
|
||||
|
||||
=== External MNCC handler
|
||||
|
||||
When the external MNCC handler is enabled, OsmoNITB will not perform any
|
||||
internal call switching, but delegate all call-control handling towards
|
||||
the external MNCC program connected via the MNCC socket.
|
||||
|
||||
If you intend to operate OsmoNITB with external MNCC handler, you have
|
||||
to start it with the `-m` or `--mncc-sock` command line option.
|
||||
|
||||
At the time of this writing, the only external application implementing
|
||||
the MNCC interface compatible with the OsmoNITB MNCC socket was `lcr`,
|
||||
the Linux Call Router.
|
||||
|
||||
=== MNCC protocol description
|
||||
|
||||
The protocol follows the primitives specified in 3GPP TS 04.07 Chapter
|
||||
7.1. The encoding of the primitives is provided in the `openbsc/mncc.h`
|
||||
header file, which uses some common definitions from
|
||||
`osmocom/gsm/mncc.h` (part of libosmocore.git).
|
||||
|
||||
However, OsmoNITB MNCC specifies a number of additional primitives
|
||||
beyond those listed in the 3GPP specification.
|
||||
|
||||
The different calls in the network are distinguished by their callref
|
||||
(call reference), which is a unique unsigned 32bit integer.
|
||||
|
||||
==== MNCC_HOLD_IND
|
||||
|
||||
Direction: NITB -> Handler
|
||||
|
||||
A 'CC HOLD' message was received from the MS.
|
||||
|
||||
==== MNCC_HOLD_CNF
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Acknowledge a previously-received 'CC HOLD' message, causes the
|
||||
transmission of a 'CC HOLD ACK' message to the MS.
|
||||
|
||||
==== MNCC_HOLD_REJ
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Reject a previously-received 'CC HOLD' message, causes the
|
||||
transmission of a 'CC HOLD REJ' message to the MS.
|
||||
|
||||
==== MNCC_RETRIEVE_IND
|
||||
|
||||
Direction: NITB -> Handler
|
||||
|
||||
A 'CC RETRIEVE' message was received from the MS.
|
||||
|
||||
==== MNCC_RETRIEVE_CNF
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Acknowledge a previously-received 'CC RETRIEVE' message, causes the
|
||||
transmission of a 'CC RETRIEVE ACK' message to the MS.
|
||||
|
||||
|
||||
==== MNCC_RETRIEVE_REJ
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Reject a previously-received 'CC RETRIEVE' message, causes the
|
||||
transmission of a 'CC RETRIEVE REJ' message to the MS.
|
||||
|
||||
==== MNCC_USERINFO_REQ
|
||||
|
||||
Direction: NITB -> Handler
|
||||
|
||||
Causes a 'CC USER INFO' message to be sent to the MS.
|
||||
|
||||
==== MNCC_USERINFO_IND
|
||||
|
||||
Direction: NITB -> Handler
|
||||
|
||||
Indicates that a 'CC USER-USER' message has been received from the MS.
|
||||
|
||||
==== MNCC_BRIDGE
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Requests that the TCH (voice) channels of two calls shall be
|
||||
inter-connected. This is the old-fashioned way of using MNCC,
|
||||
primarily required for circuit-switched BTSs whose TRAU frames are
|
||||
received via an E1 interface card on the NITB machine.
|
||||
|
||||
==== MNCC_FRAME_RECV
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Enable the forwarding of TCHF voice frames via the MNCC interface in
|
||||
NITB->Handler direction for the specified call.
|
||||
|
||||
==== MNCC_FRAME_DROP
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Disable the forwarding of TCHF voice frames via the MNCC interface in
|
||||
NITB->Handler direction for the specified call.
|
||||
|
||||
==== MNCC_LCHAN_MODIFY
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Modify the current dedicated radio channel from signalling to voice, or
|
||||
if it is a signalling-only channel (SDCCH), assign a TCH to the MS.
|
||||
|
||||
==== MNCC_RTP_CREATE
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Create a RTP socket for this call at the BTS/TRAU that serves this BTS.
|
||||
|
||||
==== MNCC_RTP_CONNECT
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Connect the RTP socket of this call to the given remote IP address and
|
||||
port.
|
||||
|
||||
==== MNCC_RTP_FREE
|
||||
|
||||
Direction: Handler -> NITB
|
||||
|
||||
Release a RTP connection for one given call.
|
||||
|
||||
==== GSM_TCHF_FRAME
|
||||
|
||||
Direction: both
|
||||
|
||||
Transfer the payload of a GSM Full-Rate (FR) voice frame between the
|
||||
NITB and an external MNCC handler.
|
||||
|
||||
==== GSM_TCHF_FRAME_EFR
|
||||
|
||||
Direction: both
|
||||
|
||||
Transfer the payload of a GSM Enanced Full-Rate (EFR) voice frame
|
||||
between the NITB and an external MNCC handler.
|
||||
|
||||
==== GSM_TCHH_FRAME
|
||||
|
||||
Direction: both
|
||||
|
||||
Transfer the payload of a GSM Half-Rate (HR) voice frame between the
|
||||
NITB and an external MNCC handler.
|
||||
|
||||
==== GSM_TCH_FRAE_AMR
|
||||
|
||||
Direction: both
|
||||
|
||||
Transfer the payload of a GSM Adaptive-Multi-Rate (AMR) voice frame
|
||||
between the NITB and an external MNCC handler.
|
||||
|
||||
==== GSM_BAD_FRAME
|
||||
|
||||
Direction: NITB -> Handler
|
||||
|
||||
Indicate that no valid voice frame, but a 'bad frame' was received over
|
||||
the radio link from the MS.
|
|
@ -0,0 +1,139 @@
|
|||
[[net]]
|
||||
== OsmoNITB Core Network Subsystem
|
||||
|
||||
The OsmoNITB Core Network is a minimalistic implementation of the
|
||||
classic MSC/VLR/HLR/AUC/SMSC components. None of the standardized core
|
||||
network protocols (such as SCCP/TCAP/MAP) are used, interfaces between
|
||||
VLR and HLR are simple function calls inside the same software package.
|
||||
|
||||
OsmoNITB can thus provide autonomous voice and SMS services to its
|
||||
coverage area, but it cannot provide roaming interfaces to classic GSM
|
||||
operators. To support this configuration, it is suggested to use the
|
||||
OsmoBSC variant of OpenBSC and interface it with a conventional MSC
|
||||
using A-over-IP protocol.
|
||||
|
||||
If you have classic GSM network/operator background, many of the
|
||||
concepts used in OsmoNITB will appear foreign to you, as they are very
|
||||
unlike the conventional GSM networks that you have worked with.
|
||||
|
||||
|
||||
=== Configuring the Core Network
|
||||
|
||||
Like everything else, the core network related parameters are configured
|
||||
using the VTY. The respective parameters are underneath the
|
||||
`network` config node.
|
||||
|
||||
You can get to that node by issuing the following commands:
|
||||
|
||||
.Entering the config network node
|
||||
----
|
||||
OpenBSC> enable
|
||||
OpenBSC# configure terminal
|
||||
OpenBSC(config)# network
|
||||
OpenBSC(config-net)#
|
||||
----
|
||||
|
||||
A full reference to them can be found in the _OsmoNITB VTY reference
|
||||
manual_ <<vty-ref-osmonitb>>. This section will only introduce the most
|
||||
commonly used settings in detail.
|
||||
|
||||
[TIP]
|
||||
====
|
||||
You can always use the `list` VTY command to get a list of all possible
|
||||
commands at the current node.
|
||||
====
|
||||
|
||||
|
||||
=== Configuring the MCC/MNC
|
||||
|
||||
The key identities of every GSM PLMN is the MCC and MNC. They are
|
||||
identical over the entire network. In most cases, the MCC/MNC will be
|
||||
allocated to the operator by the respective local regulatory authority.
|
||||
For example, to set the MCC/MNC of 262-89, you may enter:
|
||||
|
||||
.Configuring the MCC/MNC
|
||||
----
|
||||
OpenBSC(config-net)# network country code 262
|
||||
OpenBSC(config-net)# mobile network code 89
|
||||
----
|
||||
|
||||
|
||||
=== Configuring MM INFO
|
||||
|
||||
The __MM INFO__ procedure can be used after a successful __LOCATION
|
||||
UPDATE__ in order to transmit the human-readable network name as well as
|
||||
local time zone information to the MS. gq
|
||||
|
||||
By default, MM INFO is not active. You can activate it, and set its
|
||||
configuration using the VTY. An example is provided below.
|
||||
|
||||
.Configuring MM INFO
|
||||
----
|
||||
OpenBSC(config-net)# mm info 1
|
||||
OpenBSC(config-net)# short name OpenBSC
|
||||
OpenBSC(config-net)# long name OpenBSC
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Not all phone support the MM INFO procedure. Unless they already are
|
||||
factory-programmed to contain the name for your MCC/MNC, then they will
|
||||
likely only provide a numeric display of the network name, such as
|
||||
__262-89__ or with the country code transformed into a letter, such as
|
||||
__D 89__.
|
||||
====
|
||||
|
||||
The time information transmitted is determined by the local system time
|
||||
of the operating system on which OsmoNITB is running. As BTSs attached
|
||||
to one OsmoNITB can reside in different time zones, it is possible to
|
||||
use the `timezone` command at each BTS node to set different time
|
||||
zone offsets in hours and quarter hours.
|
||||
|
||||
|
||||
=== Setting the NECI bit
|
||||
|
||||
NECI (New Establishment Cause Indication) is an optional change of the
|
||||
definition for establishment cause in the RACH burst. Among other
|
||||
things, in a network with NECI, a MS can explicitly indicate its TCH/H
|
||||
capability while asking for a dedicated radio channel.
|
||||
|
||||
It is strongly recommended to use NECI. You can do so by issuing the following command:
|
||||
.Enabling NECI
|
||||
----
|
||||
OpenBSC(config-net)# neci 1
|
||||
----
|
||||
|
||||
|
||||
=== Configuring Handover
|
||||
|
||||
As opposed to cell re-selection in idle mode, handover refers to the
|
||||
explicit transfer of a MS dedicated channel from one radio channel to
|
||||
another. This typically happens due to a MS moving from one cell to
|
||||
another while in an active call.
|
||||
|
||||
OsmoNITB has a number of hand-over related parameters by which the
|
||||
hand-over algorithm can be tuned. Logically, those settings are settings
|
||||
of the BSC component, but for historic reasons, they are also configured
|
||||
under the __network__ VTY node.
|
||||
|
||||
.Configuring Handover
|
||||
----
|
||||
OpenBSC(config-net)# handover 1
|
||||
OpenBSC(config-net)# handover window rxlev averaging 10
|
||||
OpenBSC(config-net)# handover window rxqual averaging 1
|
||||
OpenBSC(config-net)# handover window rxlev neighbor averaging 10
|
||||
OpenBSC(config-net)# handover power budget interval 6
|
||||
OpenBSC(config-net)# handover power budget hysteresis 3
|
||||
OpenBSC(config-net)# handover maximum distance 9999
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
If you are receiving the following error message:
|
||||
----
|
||||
OpenBSC(config-net)# handover 1
|
||||
% Cannot enable handover unless RTP Proxy mode is enabled by using the -P command line option
|
||||
----
|
||||
then you should do as indicated and make sure to start your `osmo-nitb` process using
|
||||
the `-P` command line option.
|
||||
====
|
|
@ -0,0 +1,196 @@
|
|||
[[overview]]
|
||||
== Overview
|
||||
|
||||
This manual should help you getting started with OsmoNITB. It will cover
|
||||
aspects of configuring and running the OsmoNITB.
|
||||
|
||||
[[intro_overview]]
|
||||
=== About OsmoNITB
|
||||
|
||||
OsmoNITB is one particular version of the OpenBSC software suite.
|
||||
Unlike classic, distributed, hierarchical GSM networks, OsmoNITB
|
||||
implements all parts of a GSM Network (BSC, MSC, VLR, HLR, AUC, SMSC)
|
||||
__in the box__, i.e. in one element.
|
||||
|
||||
The difference between classic GSM network architecture and the OsmoNITB
|
||||
based GSM network architecture is illustrated in <<fig-gsm-classic>> and
|
||||
<<fig-gsm-nitb>>.
|
||||
|
||||
[[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"]
|
||||
MSC [label="MSC/VLR"]
|
||||
HLR [label="HLR/AUC"]
|
||||
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"]
|
||||
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"]
|
||||
HLR [label="HLR/AUC"]
|
||||
BSC->MSC [label="A"]
|
||||
MSC->HLR [label="C"]
|
||||
MSC->EIR [label="F"]
|
||||
MSC->SMSC;
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
|
||||
=== Software Components
|
||||
|
||||
OsmoNITB contains a variety of different software components, which
|
||||
we'll quickly describe in this section.
|
||||
|
||||
==== A-bis Implementation
|
||||
|
||||
OsmoNITB implements the ETSI/3GPP specified A-bis interface, including
|
||||
_3GPP TS 48.056_ <<3gpp-ts-48-056>> (LAPD), _3GPP TS 48.058_
|
||||
<<3gpp-ts-48-058>> (RSL) and 3GPP TS 52.021 <<3gpp-ts-52-021>> (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 <<bts>> and <<bts-examples>>.
|
||||
|
||||
|
||||
==== 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 _3GPP TS 24.008_ <<3gpp-ts-24-008>> RR (Radio Resource)
|
||||
sub-layer from the MS.
|
||||
|
||||
For more information, see <<net>>, <<bts>> and <<bts-examples>>.
|
||||
|
||||
|
||||
==== HLR/AUC
|
||||
|
||||
A minimalistic implementation of the subscriber database (HLR) and
|
||||
subscriber secret key storage (AUC).
|
||||
|
||||
For more information, see <<hlr>>.
|
||||
|
||||
|
||||
==== SMSC
|
||||
|
||||
A minimal store-and-forward server for SMS, supporting both MO and MT
|
||||
SMS service, as well as multi-part messages.
|
||||
|
||||
The built-in SMSC also supports an external SMSC interface. For more
|
||||
information, see <<smpp>>.
|
||||
|
||||
|
||||
==== MSC
|
||||
|
||||
The MSC component of OsmoNITB implements the mobility management (MM)
|
||||
functions of the TS 04.08, as well as the optional security related
|
||||
procedures for cryptographic authentication and encryption.
|
||||
|
||||
Furthermore, it can handle TS 04.08 Call Control (CC), either by use of
|
||||
an internal MNCC handler, or by use of an external MNCC agent. For more
|
||||
information see <<mncc>>.
|
||||
|
||||
|
||||
==== TRAU mapper / E1 sub-channel muxer
|
||||
|
||||
Unlike classic GSM networks, OsmoNITB 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, OsmoNITB 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.
|
||||
|
||||
|
||||
==== RTP proxy
|
||||
|
||||
BTS models implementing A-bis over IP don't use classic TRAU frames but
|
||||
typically transport the voice codec frames as RTP/UDP/IP protocol.
|
||||
OsmoNITB can either instruct the BTSs to send those voice streams
|
||||
directly to each other (BTS to BTS without any intermediary), or it can
|
||||
run an internal RTP proxy for passing frames from one BTS to another.
|
||||
|
||||
.RTP flow without RTP proxy mode (default)
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir=LR;
|
||||
|
||||
MS0 [label="MS A"];
|
||||
MS1 [label="MS B"];
|
||||
BTS0 [label="BTS A"];
|
||||
BTS1 [label="BTS B"];
|
||||
NITB;
|
||||
|
||||
MS0 -> BTS0;
|
||||
MS1 -> BTS1;
|
||||
BTS0 -> NITB [label="Abis OML+RSL",dir=both];
|
||||
BTS1 -> NITB [label="Abis OML+RSL",dir=both];
|
||||
BTS0 -> BTS1 [label="RTP",dir=both]
|
||||
}
|
||||
----
|
||||
|
||||
.RTP flow with RTP proxy mode
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir=LR;
|
||||
|
||||
MS0 [label="MS A"];
|
||||
MS1 [label="MS B"];
|
||||
BTS0 [label="BTS A"];
|
||||
BTS1 [label="BTS B"];
|
||||
NITB;
|
||||
|
||||
MS0 -> BTS0;
|
||||
MS1 -> BTS1;
|
||||
BTS0 -> NITB [label="Abis OML+RSL",dir=both];
|
||||
BTS1 -> NITB [label="Abis OML+RSL",dir=both];
|
||||
BTS0 -> NITB [label="RTP",dir=both]
|
||||
BTS1 -> NITB [label="RTP",dir=both]
|
||||
}
|
||||
----
|
|
@ -0,0 +1,60 @@
|
|||
== Running OsmoNITB
|
||||
|
||||
The OsmoNITB executable (`osmo-nitb`) offers the following command-line
|
||||
arguments:
|
||||
|
||||
==== SYNOPSIS
|
||||
|
||||
*osmo-nitb* [-h|-V] [-d 'DBGMASK'] [-D] [-c 'CONFIGFILE'] [-s] [-T] [-e 'LOGLEVEL'] [-l 'DATABASE'] [-a] [-P] [-m] [-C] [-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 <<logging>> 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 <<logging>>
|
||||
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
|
||||
<<logging>> 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
|
||||
<<logging>> for more information.
|
||||
*-l, --database 'DATABASE'*::
|
||||
Specify the file name of the SQLite3 database to use as HLR/AUC
|
||||
storage
|
||||
*-a, --authorize-everyone*::
|
||||
Authorize every subscriber to the network. This corresponds to
|
||||
the `auth-policy open` VTY configuration option.
|
||||
+
|
||||
WARNING:: This is dangerous as you may disrupt sevices to
|
||||
subscribers that are not part of your network! Don't use unless
|
||||
you absolutely know what you're doing!
|
||||
*-P, --rtp-proxy*::
|
||||
Enable the RTP proxy code inside OsmoNITB. This will force all
|
||||
voice RTP data to pass through OsmoNITB, rather than going
|
||||
directly from BTS to MGW, or BTS to BTS.
|
||||
*-m, --mncc-sock*::
|
||||
Enable the MNCC socket for an external MNCC handler. See
|
||||
<<mncc>> for further information.
|
||||
*-C, --no-dbcounter*::
|
||||
Disable the regular periodic synchronization of statistics
|
||||
counters to the database.
|
||||
*-r, --rf-ctl 'RFCTL'*::
|
||||
Offer a Unix domain socket for RF control at the path/filename
|
||||
'RFCTL' in the file system.
|
|
@ -0,0 +1,94 @@
|
|||
[[smpp]]
|
||||
== Short Message Peer to Peer (SMPP)
|
||||
|
||||
The _Short Message Peer to Peer (SMPP) Protocol_ <<smpp-34>> has been
|
||||
used for the communication with SMSCs. OsmoNITB implements version 3.4
|
||||
of the protocol. Using this interface one can send MT-SMS to an attached
|
||||
subscriber or receive unrouted MO-SMS.
|
||||
|
||||
SMPP describes a situation where multiple ESMEs (External SMS Entities)
|
||||
interact with a SMSC (SMS Service Center) via the SMPP protocol. Each
|
||||
entity is identified by its System Id. The System ID is a character
|
||||
string which is configured by the system administrator.
|
||||
|
||||
OsmoNITB implements the SMSC side of SMPP and subsequently acts as a TCP
|
||||
server accepting incoming connections from ESME client programs.
|
||||
|
||||
Each ESME identifies itself to the SMSC with its system-id and an
|
||||
optional shared password.
|
||||
|
||||
|
||||
=== Global SMPP configuration
|
||||
|
||||
|
||||
There is a `smpp` vty node at the top level of the OsmoNITB
|
||||
configuration. Under this node, the global SMPP configuration is
|
||||
performed.
|
||||
|
||||
|
||||
Use the `local-tcp-port` command to define the TCP port at which the
|
||||
OsmoNITB internal SMSC should listen for incoming SMPP connections. The
|
||||
default port assigned to SMPP is 2775.
|
||||
|
||||
Use the `system-id` command to define the System ID of the SMSC.
|
||||
|
||||
Use the `policy` parameter to define whether only explicitly configured
|
||||
ESMEs are permitted to access the SMSC (`closed`), or whether any
|
||||
ESME should be accepted (`accept-all`).
|
||||
|
||||
Use the `smpp-first` command to define if SMPP routes have higher
|
||||
precendence than MSISDNs contained in the HLR (`smpp-first`), or if
|
||||
only MSISDNs found not in the HLR should be considered for routing to
|
||||
SMPP (`no smpp-first`).
|
||||
|
||||
|
||||
=== ESME configuration
|
||||
|
||||
nder the `smpp` vty node, you can add any number of `esme` nodes, one
|
||||
for each ESME that you wish to configure.
|
||||
|
||||
Use the `esme NAME` command (where NAME corresponds to the system-id of
|
||||
the ESME to be configured) under the SMPP vty node to enter the
|
||||
configuration node for this given ESME.
|
||||
|
||||
Use the `password` command to specify the password (if any) for the
|
||||
ESME.
|
||||
|
||||
Use the `default-route` command to indicate that any MO-SMS without a
|
||||
more specific route should be routed to this ESME.
|
||||
|
||||
Use the `deliver-src-imsi` command to indicate that the SMPP DELIVER
|
||||
messages for MO SMS should state the IMSI (rather than the MSISDN) as
|
||||
source address.
|
||||
|
||||
Use the `osmocom-extensions` command to request that Osmocom specific
|
||||
extension TLVs shall be included in the SMPP PDUs. Those extensions
|
||||
include the ARFCN of the cell, the L1 transmit power of the MS, the
|
||||
timing advance, the uplink and dwnlink RxLev and RxQual, as well as the
|
||||
IMEI of the terminal at the time of generating the SMPP DELIVER PDU.
|
||||
|
||||
Use the `dcs-transparent` command to transparently pass the DCS value
|
||||
from the SMS Layer3 protocols to SMPP, instead of converting them to the
|
||||
SMPP-specific values.
|
||||
|
||||
Use the `route prefix` command to specify a route towards this ESME.
|
||||
Using routes, you specify which destination MSISDNs should be routed
|
||||
towards your ESME.
|
||||
|
||||
|
||||
=== Example configuration snippet
|
||||
|
||||
The following example configuration snippet shows a single ESME
|
||||
'galactica' with a prefix-route of all national numbers stating with
|
||||
2342:
|
||||
----
|
||||
smpp
|
||||
local-tcp-port 2775
|
||||
policy closed
|
||||
no smpp-first
|
||||
esme galactica
|
||||
password SoSayWeAll
|
||||
deliver-src-imsi
|
||||
osmocom-extensions
|
||||
route prefix national isdn 2342
|
||||
----
|
|
@ -0,0 +1,60 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1</revnumber>
|
||||
<date>August 13, 2012</date>
|
||||
<authorinitials>HF</authorinitials>
|
||||
<revremark>
|
||||
Initial version.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2</revnumber>
|
||||
<date>February 2016</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Conversion to asciidoc, removal of sysmoBTS specific parts.
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Holger</firstname>
|
||||
<surname>Freyther</surname>
|
||||
<email>hfreyther@sysmocom.de</email>
|
||||
<authorinitials>HF</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Harald</firstname>
|
||||
<surname>Welte</surname>
|
||||
<email>hwelte@sysmocom.de</email>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2012-2016</year>
|
||||
<holder>sysmocom - s.f.m.c. GmbH</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
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".
|
||||
</para>
|
||||
</legalnotice>
|
|
@ -0,0 +1,41 @@
|
|||
OsmoNITB User Manual
|
||||
====================
|
||||
Harald Welte <hwelte@sysmocom.de>
|
||||
|
||||
|
||||
include::../common/chapters/preface.adoc[]
|
||||
|
||||
include::chapters/overview.adoc[]
|
||||
|
||||
include::chapters/running.adoc[]
|
||||
|
||||
include::../common/chapters/vty.adoc[]
|
||||
|
||||
include::../common/chapters/logging.adoc[]
|
||||
|
||||
include::chapters/net.adoc[]
|
||||
|
||||
include::../common/chapters/bsc.adoc[]
|
||||
|
||||
include::../common/chapters/bts.adoc[]
|
||||
|
||||
include::chapters/bts-examples.adoc[]
|
||||
|
||||
include::chapters/hlr.adoc[]
|
||||
|
||||
include::chapters/smpp.adoc[]
|
||||
|
||||
include::chapters/mncc.adoc[]
|
||||
|
||||
include::../common/chapters/control_if.adoc[]
|
||||
|
||||
include::chapters/abis.adoc[]
|
||||
|
||||
include::../common/chapters/port_numbers.adoc[]
|
||||
|
||||
include::../common/chapters/bibliography.adoc[]
|
||||
|
||||
include::../common/chapters/glossary.adoc[]
|
||||
|
||||
include::../common/chapters/gfdl.adoc[]
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!--
|
||||
ex:ts=2:sw=42sts=2:et
|
||||
-*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
||||
-->
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
|
||||
"http://www.docbook.org/xml/5.0/dtd/docbook.dtd" [
|
||||
<!ENTITY chapter-vty SYSTEM "../common/chapters/vty.xml" >
|
||||
<!ENTITY sections-vty SYSTEM "generated/docbook_vty.xml" >
|
||||
]>
|
||||
|
||||
<book>
|
||||
<info>
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1</revnumber>
|
||||
<date>13th August 2012</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Initial</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v2</revnumber>
|
||||
<date>5th March 2014</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Update to match osmo-bsc version 0.13.0-305</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<title>OsmoNITB VTY Reference</title>
|
||||
|
||||
<copyright>
|
||||
<year>2012-2014</year>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>This work is copyright by <orgname>sysmocom - s.f.m.c. GmbH</orgname>. All rights reserved.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</info>
|
||||
|
||||
<!-- Main chapters-->
|
||||
&chapter-vty;
|
||||
</book>
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='29'>
|
||||
<child_of nodeid='4' />
|
||||
<name>MNCC Internal Configuration</name>
|
||||
<description>This node allows to configure the default codecs for
|
||||
the internal call control handling.</description>
|
||||
</node>
|
||||
<node id='31'>
|
||||
<child_of nodeid='4' />
|
||||
<name>SMPP Configuration</name>
|
||||
<description>This node allows to configure the SMPP interface
|
||||
for interfacing with external SMS applications. This section
|
||||
contains generic/common SMPP related configuration, and no
|
||||
per-ESME specific parameters.</description>
|
||||
</node>
|
||||
<node id='32'>
|
||||
<child_of nodeid='31' />
|
||||
<name>ESME Configuration</name>
|
||||
<description>This node allows to configure one particular SMPP
|
||||
ESME, which is an External SMS Entity such as a SMS based
|
||||
application server. You can define any number of ESME within
|
||||
the SMPP node of the OsmoNITB VTY.</description>
|
||||
</node>
|
||||
</vtydoc>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,41 @@
|
|||
# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/
|
||||
# Makefile from BitBake/OpenEmbedded manuals
|
||||
|
||||
EXTRA_DEPS = gen-vty-docbook
|
||||
|
||||
topdir = .
|
||||
pcu_reference = $(topdir)/osmopcu-vty-reference.xml
|
||||
manuals = $(bts_manual) $(pcu_reference)
|
||||
# types = pdf txt rtf ps xhtml html man tex texi dvi
|
||||
# types = pdf txt
|
||||
types = $(docbooktotypes)
|
||||
docbooktotypes = pdf
|
||||
# htmlcssfile =
|
||||
# htmlcss =
|
||||
|
||||
TOPDIR := ..
|
||||
ASCIIDOCS := osmopcu-usermanual
|
||||
|
||||
include $(TOPDIR)/build/Makefile.asciidoc.inc
|
||||
include $(TOPDIR)/build/Makefile.inc
|
||||
|
||||
osmopcu-usermanual.pdf: chapters/*.adoc
|
||||
|
||||
clean:
|
||||
rm -rf $(cleanfiles)
|
||||
rm -rf gen-vty-docbook
|
||||
|
||||
gen-vty-docbook: FORCE
|
||||
$(call command,xsltproc -o generated/combined1.xml \
|
||||
--stringparam with $(PWD)/../common/vty_additions.xml \
|
||||
$(MERGE_DOC) vty/osmo-pcu_vty_reference.xml, \
|
||||
XSLTPROC,Merging Common VTY)
|
||||
$(call command,xsltproc -o generated/combined2.xml \
|
||||
--stringparam with $(PWD)/vty/osmo-pcu_vty_additions.xml \
|
||||
$(MERGE_DOC) generated/combined1.xml, \
|
||||
XSLTPROC,Merging PCU VTY)
|
||||
$(call command,xsltproc ../vty_reference.xsl generated/combined2.xml > generated/docbook_vty.xml, \
|
||||
XSLTPROC,Converting PCU VTY to DocBook)
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,205 @@
|
|||
== Configuring OsmoPCU
|
||||
|
||||
Contrary to other network elements (like OsmoBSC, OsmoNITB), the
|
||||
OsmoPCU has a relatively simple minimum configuration.
|
||||
|
||||
This is primarily because most of the PCU configuration happens
|
||||
indirectly from the BSC, who passes the configuation over A-bis OML via
|
||||
OsmoBTS and its PCU socket into OsmoPCU.
|
||||
|
||||
A minimal OsmoPCU configuration file is provided below for your reference:
|
||||
|
||||
.Example: Minimal OsmoPCU configuration file (`osmo-pcu.cfg`)
|
||||
----
|
||||
pcu
|
||||
flow-control-interval 10 <1>
|
||||
cs 2 <2>
|
||||
alloc-algorithm dynamic <3>
|
||||
alpha 0 <4>
|
||||
gamma 0
|
||||
----
|
||||
<1> send a BSSGP flow-control PDU every 10 seconds
|
||||
<2> start a TBF with the initial coding scheme 2
|
||||
<3> dynamically chose between single-slot or multi-slot TBF allocations
|
||||
depending on system load
|
||||
<4> disable MS power control loop
|
||||
|
||||
However, there are plenty of tuning parameters for people interested to
|
||||
optimize PCU throughput or latency according to their requirements.
|
||||
|
||||
=== Configuring the Coding Schemes and Rate Adaption
|
||||
|
||||
The BSC includes a bit-mask of permitted [E]GPRS coding schemes as part
|
||||
of the A-bis OML configuration. This is passed from the BTS via the PCU
|
||||
socket into OsmoPCU.
|
||||
|
||||
Some additional parameters can be set as described below.
|
||||
|
||||
==== Initial Coding Scheme
|
||||
|
||||
You can use the `cs <1-4> [<1-4>]` command at the `pcu` VTY config node
|
||||
to set the initial GPRS coding scheme to be used. The optional second
|
||||
value allows to specify a different initial coding scheme for uplink.
|
||||
|
||||
==== Maximum Coding Scheme
|
||||
|
||||
You can use the `cs max <1-4> [<1-4>]` command at the `pcu` VTY config
|
||||
node to set the maximum coding scheme that should be used as part of the
|
||||
rate adaption.
|
||||
|
||||
==== Rate Adaption Error Thresholds
|
||||
|
||||
You can use the `cs threshold <0-100> <0-100>` command at the `pcu` VTY
|
||||
config node to determine the upper and lower limit for the error rate
|
||||
percentage to use in the rate adaption. If the upper threshold is
|
||||
reached, a lower coding sheme is chosen, and if the lower threshold is
|
||||
reached, a higher coding scheme is chosen.
|
||||
|
||||
==== Rate Adation Link Quality Thresholds
|
||||
|
||||
You can use the `cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3
|
||||
<0-35> <0-35> cs4 <0-35>` command at the `pcu` VTY config node to tune
|
||||
the link quality ranges for the respecive coding schemes.
|
||||
|
||||
==== Data Size based CS downgrade Threshold
|
||||
|
||||
You can use the `cs downgrade-threshold <1-10000>` command at the `pcu`
|
||||
VTY config node to ask the PCU to down-grade the coding scheme if less
|
||||
than the specified number of octets are left to be transmitted.
|
||||
|
||||
=== Miscellaneous Configuration / Tuning Parameters
|
||||
|
||||
==== Downlink TBF idle time
|
||||
|
||||
After a down-link TBF is idle (all data in the current LLC downlink
|
||||
queue for thi MS has been transmitted), we can keep the TBF established
|
||||
for a configurable time. This avoids having to go through a new one or
|
||||
two phase TBF establishment once the next data for downlink arrives.
|
||||
|
||||
You can use the `dl-tbf-idle-time <1-5000>` to specify that time in
|
||||
units of milli-seconds. The default is 2 seconds.
|
||||
|
||||
==== MS idle time
|
||||
|
||||
Using the `ms-idle-time <1-7200>` command at the `pcu` VTY config node
|
||||
you can configure the number of seconds for which the PCU should keep
|
||||
the MS data structure alive before releasing it if there are no active
|
||||
TBF for this MS.
|
||||
|
||||
The OsmoPCU default value is 60 seconds, which is slightly more than
|
||||
what 3GPP TS 24.008 recommends for T3314 (44s).
|
||||
|
||||
The MS data structure only consumes memory in the PCU and does not
|
||||
require any resources of the air interface.
|
||||
|
||||
==== Forcing two-phase access
|
||||
|
||||
If the MS is using for a single-phase access, you can still force it to
|
||||
use a two-phase access using the `two-phase-access` VTY configuration
|
||||
command at the `pcu` VTY config node.
|
||||
|
||||
=== Configuring BSSGP flow control
|
||||
|
||||
BSSGP between SGSN and PCU contains a two-level nested flow control
|
||||
mechanism:
|
||||
|
||||
. one global flow control instance for the overall (downlink) traffic
|
||||
from the SGSN to this PCU
|
||||
. a per-MS flow control instance for each individual MS served by this
|
||||
PCU
|
||||
|
||||
Each of the flow control instance is implemented as a TBF (token bucket
|
||||
filter).
|
||||
|
||||
==== Normal BSSGP Flow Control Tuning parameters
|
||||
|
||||
You can use the following commands at the `pcu` VTY config node to tune
|
||||
the the BSSGP flow control parameters:
|
||||
|
||||
`flow-control-interval <1-10>`::
|
||||
configure the interval (in seconds) between subsequent flow
|
||||
control PDUs from PCU to SGSN
|
||||
`flow-control bucket-time <1-65534>`::
|
||||
set the target downlink maximum queueing time in centi-seconds.
|
||||
The PCU will attempt to adjust the advertised bucket size to match this
|
||||
target.
|
||||
|
||||
==== Extended BSSGP Flow Control Tuning parameters
|
||||
|
||||
There are some extended flow control related parameters at the `pcu` VTY
|
||||
config node that override the automatic flow control as specified in the
|
||||
BSSGP specification. Use them with care!
|
||||
|
||||
`flow-control force-bvc-bucket-size <1-6553500>`::
|
||||
force the BVC (global) bucket size to the given number of octets
|
||||
`flow-control force-bvc-leak-rate <1-6553500>`::
|
||||
force the BVC (global) bucket leak rate to the given number of bits/s
|
||||
`flow-control force-ms-bucket-size <1-6553500>`::
|
||||
force the per-MS bucket size to the given number of octets
|
||||
`flow-control force-ms-leak-rate <1-6553500>`::
|
||||
force the per-MS bucket leak rate to the given number of bits/s
|
||||
|
||||
|
||||
=== Configuring LLC queue
|
||||
|
||||
The downlink LLC queue in the PCU towards the MS can be tuned with a
|
||||
variety of parameters at the `pcu` VTY config node, depending on your
|
||||
needs.
|
||||
|
||||
`queue lifetime <1-65534>`::
|
||||
Each downlink LLC PDU is assigned a lifetime by the SGSN, which
|
||||
is respected by the PDU *unless* you use this command to
|
||||
override the PDU lifetime with a larger value (in centi-seconds)
|
||||
`queue lifetime infinite`::
|
||||
Never drop LLC PDUs, i.e. give them an unlimited lifetime.
|
||||
`queue hysteresis <1-65535>`::
|
||||
When the downlink LLC queue is full, the PCU starts dropping
|
||||
packets. Using this parameter, we can set the lifetime
|
||||
hysteresis in centi-seconds, i.e. it will continue discarding
|
||||
until "lifetime - hysteresis" is reached.
|
||||
`queue codel`::
|
||||
Use the 'CoDel' (Controlled Delay) scheduling algorithm, which
|
||||
is designed to overcome buffer bloat. It will use a default
|
||||
interval of 4 seconds.
|
||||
`queue codel interval <1-1000>`::
|
||||
Use the 'CoDel' (Controlled Delay) scheduling algorithm, which
|
||||
is designed to overcome buffer bloat. Use the specified
|
||||
interval in centi-seconds.
|
||||
`queue idle-ack-delay <1-65535>`::
|
||||
Delay the request for an ACK after the last downlink LLC frame
|
||||
by the specified amount of centi-seconds.
|
||||
|
||||
|
||||
=== Configuring MS power control
|
||||
|
||||
GPRS MS power control works completely different than the close MS power
|
||||
control loop in circuit-switched GSM.
|
||||
|
||||
Rather than instructing the MS constantly about which transmit power to
|
||||
use, some parameters are provided to the MS by which the MS-based power
|
||||
control algorithm is tuned.
|
||||
|
||||
See 3GPP TS 05.08 for further information on the algorithm and the
|
||||
parameters.
|
||||
|
||||
You can set those parameters at the `pcu` VTY config node as follows:
|
||||
|
||||
`alpha <0-10>`::
|
||||
Alpha parameter for MS power contrl in units of 0.1.
|
||||
Make sure to set the alpha value at System Information 13 (in
|
||||
the BSC), too!
|
||||
`gamma <0-62>`::
|
||||
Set the gamma parameter for MS power control in units of dB.
|
||||
|
||||
|
||||
=== Enabling EGPRS
|
||||
|
||||
If you would like to test the currently (experimental) EGPRS support of
|
||||
OsmoPCU, you can enable it using the `egprs` command at the `pcu` VTY
|
||||
config node.
|
||||
|
||||
WARNING: EPGRS functionality is highly experimental at the time of this
|
||||
writing. Please only use if you actively would like to participate in
|
||||
the OsmoPCU EGPRS development and/or testing. You will also need an
|
||||
EGPRS capable OsmoBTS+PHY, which means `osmo-bts-sysmo` or
|
||||
`osmo-bts-litecell15` with their associated PHY.
|
|
@ -0,0 +1,67 @@
|
|||
== Overview
|
||||
|
||||
=== About OsmoPCU
|
||||
|
||||
OsmoPCU is the Osmocom implementation of the GPRS PCU (Packet Control
|
||||
Unit) element inside the GPRS network.
|
||||
|
||||
The OsmoPCU is co-located within the BTS and connects to OsmoBTS via its
|
||||
PCU socket inteface.
|
||||
|
||||
On the other side, OsmoPCU is connected via the Gb interface to the
|
||||
SGSN.
|
||||
|
||||
[[fig-gprs-pcubts]]
|
||||
.GPRS network architecture with PCU in BTS
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir=LR;
|
||||
MS0 [label="MS"]
|
||||
MS1 [label="MS"]
|
||||
MS0->BTS [label="Um"]
|
||||
MS1->BTS [label="Um"]
|
||||
BTS->BSC [label="Abis"]
|
||||
BSC->MSC [label="A"]
|
||||
BTS->PCU [label="pcu_sock"]
|
||||
PCU->SGSN [label="Gb"]
|
||||
SGSN->GGSN [label="GTP"]
|
||||
}
|
||||
----
|
||||
|
||||
=== Software Components
|
||||
|
||||
OsmoPCU consists of a variety of components, including
|
||||
|
||||
* Gb interface (NS/BSSGP protocol)
|
||||
* `pcu_sock` interface towards OsmoBTS
|
||||
* TBF management for uplink and downlink TBF
|
||||
* RLC/MAC protocol implementation
|
||||
* per-MS context for each MS currently served
|
||||
* CSN.1 encoding/decoding routines
|
||||
|
||||
==== Gb Implementation
|
||||
|
||||
OsmoPCU implements the ETSI/3GPP specified Gb interface, including TS
|
||||
08.16 (NS), TS 08.18 (BSSGP) protocols. As transport layer for NS, it
|
||||
supports NS/IP (NS encapsulated in UDP/IP).
|
||||
|
||||
The actual Gb Implementation is part of the libosmogb library, which is
|
||||
in turn part of the libosmocore software package. This allows the same
|
||||
Gb implementation to be used from OsmoPCU, OsmoGbProxy as well as
|
||||
OsmoSGSN.
|
||||
|
||||
==== `pcu_sock` Interface to OsmoBTS
|
||||
|
||||
The interface towards OsmoBTS is called 'pcu_sock' and implemented as a
|
||||
set of non-standardized primitives over a unix domain socket. The
|
||||
default file system path for this socket is `/tmp/pcu_bts`.
|
||||
|
||||
The PCU socket can be changed on both OmsoBTS and OsmoPCU to a different
|
||||
file/path name, primarily to permit running multiple independent BTS+PCU
|
||||
pairs on a single Linux machine without having to use filesystem
|
||||
namespaces or other complex configurations.
|
||||
|
||||
NOTE: If you change the PCU socket path on OsmoBTS by means of the
|
||||
`pcu-socket` VTY configuration command, you must ensure to make the
|
||||
identical change on the OsmoPCU side.
|
|
@ -0,0 +1,33 @@
|
|||
== Running OsmoPCU
|
||||
|
||||
The OsmoPCU executable (`osmo-pcu`) offers the following command-line
|
||||
options:
|
||||
|
||||
|
||||
=== SYNOPSIS
|
||||
|
||||
*osmo-pcu* [-h|-V] [-D] [-c 'CONFIGFILE'] [-r 'PRIO'] [-m 'MCC'] [-n 'MNC']
|
||||
|
||||
|
||||
=== 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, --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 `osmo-pcu.cfg` in the current
|
||||
working directory.
|
||||
*-r, --realtime 'PRIO'*::
|
||||
Enable use of the Linux kernel realtime priority scheduler with
|
||||
the specified priority.
|
||||
It is recommended you use this option on low-performance
|
||||
embedded systems or systems that encounter high non-GSM/GPRS
|
||||
load.
|
||||
*-m, --mcc 'MCC'*::
|
||||
Use the given MCC instead of that provided by BTS via PCU socket
|
||||
*-n, --mnc 'MNC'*::
|
||||
Use the given MNC instead of that provided by BTS via PCU socket
|
|
@ -0,0 +1,40 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1</revnumber>
|
||||
<date>February 13, 2016</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Initial version.
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Harald</firstname>
|
||||
<surname>Welte</surname>
|
||||
<email>hwelte@sysmocom.de</email>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2013-2016</year>
|
||||
<holder>sysmocom - s.f.m.c. GmbH</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
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 no Invariant Sections, no Front-Cover Texts,
|
||||
and no Back-Cover Texts. A copy of the license is included in
|
||||
the section entitled "GNU Free Documentation License".
|
||||
</para>
|
||||
</legalnotice>
|
|
@ -0,0 +1,26 @@
|
|||
OsmoPCU User Manual
|
||||
===================
|
||||
Harald Welte <hwelte@sysmocom.de>
|
||||
|
||||
|
||||
include::../common/chapters/preface.adoc[]
|
||||
|
||||
include::chapters/overview.adoc[]
|
||||
|
||||
include::chapters/running.adoc[]
|
||||
|
||||
include::../common/chapters/vty.adoc[]
|
||||
|
||||
include::../common/chapters/logging.adoc[]
|
||||
|
||||
include::chapters/configuration.adoc[]
|
||||
|
||||
include::../common/chapters/gb.adoc[]
|
||||
|
||||
include::../common/chapters/port_numbers.adoc[]
|
||||
|
||||
include::../common/chapters/bibliography.adoc[]
|
||||
|
||||
include::../common/chapters/glossary.adoc[]
|
||||
|
||||
include::../common/chapters/gfdl.adoc[]
|
|
@ -0,0 +1,37 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!--
|
||||
ex:ts=2:sw=42sts=2:et
|
||||
-*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
||||
-->
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
|
||||
"http://www.docbook.org/xml/5.0/dtd/docbook.dtd" [
|
||||
<!ENTITY chapter-vty SYSTEM "../common/chapters/vty.xml">
|
||||
<!ENTITY sections-vty SYSTEM "generated/docbook_vty.xml" >
|
||||
]>
|
||||
|
||||
<book>
|
||||
<info>
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1</revnumber>
|
||||
<date>5th March 2014</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Initial version for 0.2-307</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<title>OsmoPCU VTY Reference</title>
|
||||
|
||||
<copyright>
|
||||
<year>2014</year>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>This work is copyright by <orgname>sysmocom - s.f.m.c. GmbH</orgname>. All rights reserved.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</info>
|
||||
|
||||
<!-- Main chapters-->
|
||||
&chapter-vty;
|
||||
</book>
|
|
@ -0,0 +1,9 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='14'>
|
||||
<child_of id='4' />
|
||||
<name>PCU Configuration Node</name>
|
||||
<description>The main PCU configuration including the timeslot
|
||||
assignment algorithm and other parameters.</description>
|
||||
</node>
|
||||
</vtydoc>
|
||||
|
|
@ -0,0 +1,941 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='0'>
|
||||
</node>
|
||||
<node id='1'>
|
||||
<command id='show version'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='version' doc='Displays program version' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show online-help'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='online-help' doc='Online help' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='list'>
|
||||
<params>
|
||||
<param name='list' doc='Print command list' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='exit'>
|
||||
<params>
|
||||
<param name='exit' doc='Exit current mode and down to previous mode' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='help'>
|
||||
<params>
|
||||
<param name='help' doc='Description of the interactive help system' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='enable'>
|
||||
<params>
|
||||
<param name='enable' doc='Turn on privileged mode command' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='terminal length <0-512>'>
|
||||
<params>
|
||||
<param name='terminal' doc='Set terminal line parameters' />
|
||||
<param name='length' doc='Set number of lines on a screen' />
|
||||
<param name='<0-512>' doc='Number of lines on screen (0 for no pausing)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='terminal no length'>
|
||||
<params>
|
||||
<param name='terminal' doc='Set terminal line parameters' />
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='length' doc='Set number of lines on a screen' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='echo .MESSAGE'>
|
||||
<params>
|
||||
<param name='echo' doc='Echo a message back to the vty' />
|
||||
<param name='.MESSAGE' doc='The message to echo' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='who'>
|
||||
<params>
|
||||
<param name='who' doc='Display who is on vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show history'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='history' doc='Display the session command history' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging enable'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='enable' doc='Enables logging to this vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging disable'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='disable' doc='Disables logging to this vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging filter all (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='filter' doc='Filter log messages' />
|
||||
<param name='all' doc='Do you want to log all messages?' />
|
||||
<param name='0' doc='Only print messages matched by other filters' />
|
||||
<param name='1' doc='Bypass filter and print all messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging color (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='color' doc='Configure color-printing for log messages' />
|
||||
<param name='0' doc='Don't use color for printing messages' />
|
||||
<param name='1' doc='Use color for printing messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging timestamp (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='timestamp' doc='Configure log message timestamping' />
|
||||
<param name='0' doc='Don't prefix each log message' />
|
||||
<param name='1' doc='Prefix each log message with current timestamp' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging set-log-mask MASK'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='set-log-mask' doc='Set the logmask of this logging target' />
|
||||
<param name='MASK' doc='The logmask to use' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging set log mask MASK'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='set' doc='Decide which categories to output.' />
|
||||
<param name='log' doc='Log commands' />
|
||||
<param name='mask' doc='Mask commands' />
|
||||
<param name='MASK' doc='The logmask to use' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging level (all|csn1|l1if|rlcmac|rlcmacdata|rlcmacdl|rlcmacul|rlcmacsched|rlcmacmeas|bssgp|pcu|lglobal|llapd|linp|lmux|lmi|lmib|lsms) (everything|debug|info|notice|error|fatal)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='level' doc='Set the log level for a specified category' />
|
||||
<param name='all' doc='Global setting for all subsystems' />
|
||||
<param name='csn1' doc='Concrete Syntax Notation One (CSN1)' />
|
||||
<param name='l1if' doc='GPRS PCU L1 interface (L1IF)' />
|
||||
<param name='rlcmac' doc='GPRS RLC/MAC layer (RLCMAC)' />
|
||||
<param name='rlcmacdata' doc='GPRS RLC/MAC layer Data (RLCMAC)' />
|
||||
<param name='rlcmacdl' doc='GPRS RLC/MAC layer Downlink (RLCMAC)' />
|
||||
<param name='rlcmacul' doc='GPRS RLC/MAC layer Uplink (RLCMAC)' />
|
||||
<param name='rlcmacsched' doc='GPRS RLC/MAC layer Scheduling (RLCMAC)' />
|
||||
<param name='rlcmacmeas' doc='GPRS RLC/MAC layer Measurements (RLCMAC)' />
|
||||
<param name='bssgp' doc='GPRS BSS Gateway Protocol (BSSGP)' />
|
||||
<param name='pcu' doc='GPRS Packet Control Unit (PCU)' />
|
||||
<param name='lglobal' doc='Library-internal global log family' />
|
||||
<param name='llapd' doc='LAPD in libosmogsm' />
|
||||
<param name='linp' doc='A-bis Intput Subsystem' />
|
||||
<param name='lmux' doc='A-bis B-Subchannel TRAU Frame Multiplex' />
|
||||
<param name='lmi' doc='A-bis Input Driver for Signalling' />
|
||||
<param name='lmib' doc='A-bis Input Driver for B-Channels (voice)' />
|
||||
<param name='lsms' doc='Layer3 Short Message Service (SMS)' />
|
||||
<param name='everything' doc='Log simply everything' />
|
||||
<param name='debug' doc='Log debug messages and higher levels' />
|
||||
<param name='info' doc='Log informational messages and higher levels' />
|
||||
<param name='notice' doc='Log noticable messages and higher levels' />
|
||||
<param name='error' doc='Log error messages and higher levels' />
|
||||
<param name='fatal' doc='Log only fatal messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show logging vty'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='logging' doc='Show current logging configuration' />
|
||||
<param name='vty' doc='Show current logging configuration for this vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show alarms'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='alarms' doc='Show current logging configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show bts statistics'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='bts' doc='BTS related functionality' />
|
||||
<param name='statistics' doc='Statistics' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show tbf all'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='tbf' doc='information about all current TBFs' />
|
||||
<param name='all' doc='(null)' />
|
||||
</params>
|
||||
</command>
|
||||
</node>
|
||||
<node id='2'>
|
||||
</node>
|
||||
<node id='3'>
|
||||
<command id='help'>
|
||||
<params>
|
||||
<param name='help' doc='Description of the interactive help system' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='list'>
|
||||
<params>
|
||||
<param name='list' doc='Print command list' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write terminal'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='terminal' doc='Write to terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write file'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='file' doc='Write to configuration file' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write memory'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='memory' doc='Write configuration to the file (same as write file)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show running-config'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='running-config' doc='running configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='exit'>
|
||||
<params>
|
||||
<param name='exit' doc='Exit current mode and down to previous mode' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='disable'>
|
||||
<params>
|
||||
<param name='disable' doc='Turn off privileged mode command' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='configure terminal'>
|
||||
<params>
|
||||
<param name='configure' doc='Configuration from vty interface' />
|
||||
<param name='terminal' doc='Configuration terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='copy running-config startup-config'>
|
||||
<params>
|
||||
<param name='copy' doc='Copy configuration' />
|
||||
<param name='running-config' doc='Copy running config to... ' />
|
||||
<param name='startup-config' doc='Copy running config to startup config (same as write file)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show startup-config'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='startup-config' doc='Contentes of startup configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show version'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='version' doc='Displays program version' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show online-help'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='online-help' doc='Online help' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='terminal length <0-512>'>
|
||||
<params>
|
||||
<param name='terminal' doc='Set terminal line parameters' />
|
||||
<param name='length' doc='Set number of lines on a screen' />
|
||||
<param name='<0-512>' doc='Number of lines on screen (0 for no pausing)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='terminal no length'>
|
||||
<params>
|
||||
<param name='terminal' doc='Set terminal line parameters' />
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='length' doc='Set number of lines on a screen' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='echo .MESSAGE'>
|
||||
<params>
|
||||
<param name='echo' doc='Echo a message back to the vty' />
|
||||
<param name='.MESSAGE' doc='The message to echo' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='who'>
|
||||
<params>
|
||||
<param name='who' doc='Display who is on vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show history'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='history' doc='Display the session command history' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='terminal monitor'>
|
||||
<params>
|
||||
<param name='terminal' doc='Set terminal line parameters' />
|
||||
<param name='monitor' doc='Copy debug output to the current terminal line' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='terminal no monitor'>
|
||||
<params>
|
||||
<param name='terminal' doc='Set terminal line parameters' />
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='monitor' doc='Copy debug output to the current terminal line' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging enable'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='enable' doc='Enables logging to this vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging disable'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='disable' doc='Disables logging to this vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging filter all (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='filter' doc='Filter log messages' />
|
||||
<param name='all' doc='Do you want to log all messages?' />
|
||||
<param name='0' doc='Only print messages matched by other filters' />
|
||||
<param name='1' doc='Bypass filter and print all messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging color (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='color' doc='Configure color-printing for log messages' />
|
||||
<param name='0' doc='Don't use color for printing messages' />
|
||||
<param name='1' doc='Use color for printing messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging timestamp (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='timestamp' doc='Configure log message timestamping' />
|
||||
<param name='0' doc='Don't prefix each log message' />
|
||||
<param name='1' doc='Prefix each log message with current timestamp' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging set-log-mask MASK'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='set-log-mask' doc='Set the logmask of this logging target' />
|
||||
<param name='MASK' doc='The logmask to use' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging set log mask MASK'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='set' doc='Decide which categories to output.' />
|
||||
<param name='log' doc='Log commands' />
|
||||
<param name='mask' doc='Mask commands' />
|
||||
<param name='MASK' doc='The logmask to use' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging level (all|csn1|l1if|rlcmac|rlcmacdata|rlcmacdl|rlcmacul|rlcmacsched|rlcmacmeas|bssgp|pcu|lglobal|llapd|linp|lmux|lmi|lmib|lsms) (everything|debug|info|notice|error|fatal)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='level' doc='Set the log level for a specified category' />
|
||||
<param name='all' doc='Global setting for all subsystems' />
|
||||
<param name='csn1' doc='Concrete Syntax Notation One (CSN1)' />
|
||||
<param name='l1if' doc='GPRS PCU L1 interface (L1IF)' />
|
||||
<param name='rlcmac' doc='GPRS RLC/MAC layer (RLCMAC)' />
|
||||
<param name='rlcmacdata' doc='GPRS RLC/MAC layer Data (RLCMAC)' />
|
||||
<param name='rlcmacdl' doc='GPRS RLC/MAC layer Downlink (RLCMAC)' />
|
||||
<param name='rlcmacul' doc='GPRS RLC/MAC layer Uplink (RLCMAC)' />
|
||||
<param name='rlcmacsched' doc='GPRS RLC/MAC layer Scheduling (RLCMAC)' />
|
||||
<param name='rlcmacmeas' doc='GPRS RLC/MAC layer Measurements (RLCMAC)' />
|
||||
<param name='bssgp' doc='GPRS BSS Gateway Protocol (BSSGP)' />
|
||||
<param name='pcu' doc='GPRS Packet Control Unit (PCU)' />
|
||||
<param name='lglobal' doc='Library-internal global log family' />
|
||||
<param name='llapd' doc='LAPD in libosmogsm' />
|
||||
<param name='linp' doc='A-bis Intput Subsystem' />
|
||||
<param name='lmux' doc='A-bis B-Subchannel TRAU Frame Multiplex' />
|
||||
<param name='lmi' doc='A-bis Input Driver for Signalling' />
|
||||
<param name='lmib' doc='A-bis Input Driver for B-Channels (voice)' />
|
||||
<param name='lsms' doc='Layer3 Short Message Service (SMS)' />
|
||||
<param name='everything' doc='Log simply everything' />
|
||||
<param name='debug' doc='Log debug messages and higher levels' />
|
||||
<param name='info' doc='Log informational messages and higher levels' />
|
||||
<param name='notice' doc='Log noticable messages and higher levels' />
|
||||
<param name='error' doc='Log error messages and higher levels' />
|
||||
<param name='fatal' doc='Log only fatal messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show logging vty'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='logging' doc='Show current logging configuration' />
|
||||
<param name='vty' doc='Show current logging configuration for this vty' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show alarms'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='alarms' doc='Show current logging configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show bts statistics'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='bts' doc='BTS related functionality' />
|
||||
<param name='statistics' doc='Statistics' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show tbf all'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='tbf' doc='information about all current TBFs' />
|
||||
<param name='all' doc='(null)' />
|
||||
</params>
|
||||
</command>
|
||||
</node>
|
||||
<node id='4'>
|
||||
<command id='help'>
|
||||
<params>
|
||||
<param name='help' doc='Description of the interactive help system' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='list'>
|
||||
<params>
|
||||
<param name='list' doc='Print command list' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write terminal'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='terminal' doc='Write to terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write file'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='file' doc='Write to configuration file' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write memory'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='memory' doc='Write configuration to the file (same as write file)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show running-config'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='running-config' doc='running configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='exit'>
|
||||
<params>
|
||||
<param name='exit' doc='Exit current mode and down to previous mode' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='end'>
|
||||
<params>
|
||||
<param name='end' doc='End current mode and change to enable mode.' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='hostname WORD'>
|
||||
<params>
|
||||
<param name='hostname' doc='Set system's network name' />
|
||||
<param name='WORD' doc='This system's network name' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no hostname [HOSTNAME]'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='hostname' doc='Reset system's network name' />
|
||||
<param name='[HOSTNAME]' doc='Host name of this router' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='password (8|) WORD'>
|
||||
<params>
|
||||
<param name='password' doc='Assign the terminal connection password' />
|
||||
<param name='8' doc='Specifies a HIDDEN password will follow' />
|
||||
<param name='' doc='dummy string ' />
|
||||
<param name='WORD' doc='The HIDDEN line password string' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='password LINE'>
|
||||
<params>
|
||||
<param name='password' doc='Assign the terminal connection password' />
|
||||
<param name='LINE' doc='The UNENCRYPTED (cleartext) line password' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='enable password (8|) WORD'>
|
||||
<params>
|
||||
<param name='enable' doc='Modify enable password parameters' />
|
||||
<param name='password' doc='Assign the privileged level password' />
|
||||
<param name='8' doc='Specifies a HIDDEN password will follow' />
|
||||
<param name='' doc='dummy string ' />
|
||||
<param name='WORD' doc='The HIDDEN 'enable' password string' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='enable password LINE'>
|
||||
<params>
|
||||
<param name='enable' doc='Modify enable password parameters' />
|
||||
<param name='password' doc='Assign the privileged level password' />
|
||||
<param name='LINE' doc='The UNENCRYPTED (cleartext) 'enable' password' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no enable password'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='enable' doc='Modify enable password parameters' />
|
||||
<param name='password' doc='Assign the privileged level password' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='banner motd default'>
|
||||
<params>
|
||||
<param name='banner' doc='Set banner string' />
|
||||
<param name='motd' doc='Strings for motd' />
|
||||
<param name='default' doc='Default string' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='banner motd file [FILE]'>
|
||||
<params>
|
||||
<param name='banner' doc='Set banner' />
|
||||
<param name='motd' doc='Banner for motd' />
|
||||
<param name='file' doc='Banner from a file' />
|
||||
<param name='[FILE]' doc='Filename' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no banner motd'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='banner' doc='Set banner string' />
|
||||
<param name='motd' doc='Strings for motd' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='service terminal-length <0-512>'>
|
||||
<params>
|
||||
<param name='service' doc='Set up miscellaneous service' />
|
||||
<param name='terminal-length' doc='System wide terminal length configuration' />
|
||||
<param name='<0-512>' doc='Number of lines of VTY (0 means no line control)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no service terminal-length [<0-512>]'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='service' doc='Set up miscellaneous service' />
|
||||
<param name='terminal-length' doc='System wide terminal length configuration' />
|
||||
<param name='[<0-512>]' doc='Number of lines of VTY (0 means no line control)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='line vty'>
|
||||
<params>
|
||||
<param name='line' doc='Configure a terminal line' />
|
||||
<param name='vty' doc='Virtual terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='service advanced-vty'>
|
||||
<params>
|
||||
<param name='service' doc='Set up miscellaneous service' />
|
||||
<param name='advanced-vty' doc='Enable advanced mode vty interface' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no service advanced-vty'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='service' doc='Set up miscellaneous service' />
|
||||
<param name='advanced-vty' doc='Enable advanced mode vty interface' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show history'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='history' doc='Display the session command history' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='log stderr'>
|
||||
<params>
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='stderr' doc='Logging via STDERR of the process' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no log stderr'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='stderr' doc='Logging via STDERR of the process' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='log file .FILENAME'>
|
||||
<params>
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='file' doc='Logging to text file' />
|
||||
<param name='.FILENAME' doc='Filename' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no log file .FILENAME'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='file' doc='Logging to text file' />
|
||||
<param name='.FILENAME' doc='Filename' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='log alarms <2-32700>'>
|
||||
<params>
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='alarms' doc='Logging alarms to osmo_strrb' />
|
||||
<param name='<2-32700>' doc='Maximum number of messages to log' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no log alarms'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='alarms' doc='Logging alarms to osmo_strrb' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='log syslog (authpriv|cron|daemon|ftp|lpr|mail|news|user|uucp)'>
|
||||
<params>
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='syslog' doc='Logging via syslog' />
|
||||
<param name='authpriv' doc='Security/authorization messages facility' />
|
||||
<param name='cron' doc='Clock daemon (cron/at) facility' />
|
||||
<param name='daemon' doc='General system daemon facility' />
|
||||
<param name='ftp' doc='Ftp daemon facility' />
|
||||
<param name='lpr' doc='Line printer facility' />
|
||||
<param name='mail' doc='Mail facility' />
|
||||
<param name='news' doc='News facility' />
|
||||
<param name='user' doc='Generic facility' />
|
||||
<param name='uucp' doc='UUCP facility' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='log syslog local <0-7>'>
|
||||
<params>
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='syslog' doc='Logging via syslog' />
|
||||
<param name='local' doc='Syslog LOCAL facility' />
|
||||
<param name='<0-7>' doc='Local facility number' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no log syslog'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='log' doc='Configure logging sub-system' />
|
||||
<param name='syslog' doc='Logging via syslog' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='pcu'>
|
||||
<params>
|
||||
<param name='pcu' doc='BTS specific configure' />
|
||||
</params>
|
||||
</command>
|
||||
</node>
|
||||
<node id='7'>
|
||||
<command id='help'>
|
||||
<params>
|
||||
<param name='help' doc='Description of the interactive help system' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='list'>
|
||||
<params>
|
||||
<param name='list' doc='Print command list' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write terminal'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='terminal' doc='Write to terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write file'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='file' doc='Write to configuration file' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write memory'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='memory' doc='Write configuration to the file (same as write file)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show running-config'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='running-config' doc='running configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='exit'>
|
||||
<params>
|
||||
<param name='exit' doc='Exit current mode and down to previous mode' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='end'>
|
||||
<params>
|
||||
<param name='end' doc='End current mode and change to enable mode.' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging filter all (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='filter' doc='Filter log messages' />
|
||||
<param name='all' doc='Do you want to log all messages?' />
|
||||
<param name='0' doc='Only print messages matched by other filters' />
|
||||
<param name='1' doc='Bypass filter and print all messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging color (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='color' doc='Configure color-printing for log messages' />
|
||||
<param name='0' doc='Don't use color for printing messages' />
|
||||
<param name='1' doc='Use color for printing messages' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging timestamp (0|1)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='timestamp' doc='Configure log message timestamping' />
|
||||
<param name='0' doc='Don't prefix each log message' />
|
||||
<param name='1' doc='Prefix each log message with current timestamp' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='logging level (all|csn1|l1if|rlcmac|rlcmacdata|rlcmacdl|rlcmacul|rlcmacsched|rlcmacmeas|bssgp|pcu|lglobal|llapd|linp|lmux|lmi|lmib|lsms) (everything|debug|info|notice|error|fatal)'>
|
||||
<params>
|
||||
<param name='logging' doc='Configure log message to this terminal' />
|
||||
<param name='level' doc='Set the log level for a specified category' />
|
||||
<param name='all' doc='Global setting for all subsystems' />
|
||||
<param name='csn1' doc='Concrete Syntax Notation One (CSN1)' />
|
||||
<param name='l1if' doc='GPRS PCU L1 interface (L1IF)' />
|
||||
<param name='rlcmac' doc='GPRS RLC/MAC layer (RLCMAC)' />
|
||||
<param name='rlcmacdata' doc='GPRS RLC/MAC layer Data (RLCMAC)' />
|
||||
<param name='rlcmacdl' doc='GPRS RLC/MAC layer Downlink (RLCMAC)' />
|
||||
<param name='rlcmacul' doc='GPRS RLC/MAC layer Uplink (RLCMAC)' />
|
||||
<param name='rlcmacsched' doc='GPRS RLC/MAC layer Scheduling (RLCMAC)' />
|
||||
<param name='rlcmacmeas' doc='GPRS RLC/MAC layer Measurements (RLCMAC)' />
|
||||
<param name='bssgp' doc='GPRS BSS Gateway Protocol (BSSGP)' />
|
||||
<param name='pcu' doc='GPRS Packet Control Unit (PCU)' />
|
||||
<param name='lglobal' doc='Library-internal global log family' />
|
||||
<param name='llapd' doc='LAPD in libosmogsm' />
|
||||
<param name='linp' doc='A-bis Intput Subsystem' />
|
||||
<param name='lmux' doc='A-bis B-Subchannel TRAU Frame Multiplex' />
|
||||
<param name='lmi' doc='A-bis Input Driver for Signalling' />
|
||||
<param name='lmib' doc='A-bis Input Driver for B-Channels (voice)' />
|
||||
<param name='lsms' doc='Layer3 Short Message Service (SMS)' />
|
||||
<param name='everything' doc='Log simply everything' />
|
||||
<param name='debug' doc='Log debug messages and higher levels' />
|
||||
<param name='info' doc='Log informational messages and higher levels' />
|
||||
<param name='notice' doc='Log noticable messages and higher levels' />
|
||||
<param name='error' doc='Log error messages and higher levels' />
|
||||
<param name='fatal' doc='Log only fatal messages' />
|
||||
</params>
|
||||
</command>
|
||||
</node>
|
||||
<node id='8'>
|
||||
<command id='help'>
|
||||
<params>
|
||||
<param name='help' doc='Description of the interactive help system' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='list'>
|
||||
<params>
|
||||
<param name='list' doc='Print command list' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write terminal'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='terminal' doc='Write to terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write file'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='file' doc='Write to configuration file' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write memory'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='memory' doc='Write configuration to the file (same as write file)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show running-config'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='running-config' doc='running configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='exit'>
|
||||
<params>
|
||||
<param name='exit' doc='Exit current mode and down to previous mode' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='end'>
|
||||
<params>
|
||||
<param name='end' doc='End current mode and change to enable mode.' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='login'>
|
||||
<params>
|
||||
<param name='login' doc='Enable password checking' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no login'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='login' doc='Enable password checking' />
|
||||
</params>
|
||||
</command>
|
||||
</node>
|
||||
<node id='14'>
|
||||
<command id='help'>
|
||||
<params>
|
||||
<param name='help' doc='Description of the interactive help system' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='list'>
|
||||
<params>
|
||||
<param name='list' doc='Print command list' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write terminal'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='terminal' doc='Write to terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write file'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='file' doc='Write to configuration file' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write memory'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
<param name='memory' doc='Write configuration to the file (same as write file)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='write'>
|
||||
<params>
|
||||
<param name='write' doc='Write running configuration to memory, network, or terminal' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='show running-config'>
|
||||
<params>
|
||||
<param name='show' doc='Show running system information' />
|
||||
<param name='running-config' doc='running configuration' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no two-phase-access'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='two-phase-access' doc='Only use two phase access when requested my MS' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='cs <1-4> [<1-4>]'>
|
||||
<params>
|
||||
<param name='cs' doc='Set the Coding Scheme to be used, (overrides BTS config)' />
|
||||
<param name='<1-4>' doc='Initial CS used' />
|
||||
<param name='[<1-4>]' doc='Alternative uplink CS' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no cs'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='cs' doc='Don't force given Coding Scheme, (use BTS config)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='queue lifetime <1-65534>'>
|
||||
<params>
|
||||
<param name='queue' doc='Packet queue options' />
|
||||
<param name='lifetime' doc='Set lifetime limit of LLC frame in centi-seconds (overrides the value given by SGSN)' />
|
||||
<param name='<1-65534>' doc='Lifetime in centi-seconds' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='queue lifetime infinite'>
|
||||
<params>
|
||||
<param name='queue' doc='Packet queue options' />
|
||||
<param name='lifetime' doc='Set lifetime limit of LLC frame in centi-seconds (overrides the value given by SGSN)' />
|
||||
<param name='infinite' doc='Infinite lifetime' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='no queue lifetime'>
|
||||
<params>
|
||||
<param name='no' doc='Negate a command or set its defaults' />
|
||||
<param name='queue' doc='Packet queue options' />
|
||||
<param name='lifetime' doc='Disable lifetime limit of LLC frame (use value given by SGSN)' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='alloc-algorithm (a|b)'>
|
||||
<params>
|
||||
<param name='alloc-algorithm' doc='Select slot allocation algorithm to use when assigning timeslots on PACCH' />
|
||||
<param name='a' doc='Single slot is assigned only' />
|
||||
<param name='b' doc='Multiple slots are assigned for semi-duplex operation' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='two-phase-access'>
|
||||
<params>
|
||||
<param name='two-phase-access' doc='Force two phase access when MS requests single phase access' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='flow-control-interval <1-10>'>
|
||||
<params>
|
||||
<param name='flow-control-interval' doc='Interval between sending subsequent Flow Control PDUs' />
|
||||
<param name='<1-10>' doc='Interval time in seconds' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='alpha <0-10>'>
|
||||
<params>
|
||||
<param name='alpha' doc='Alpha parameter for MS power control in units of 0.1 (see TS 05.08) NOTE: Be sure to set Alpha value at System information 13 too.' />
|
||||
<param name='<0-10>' doc='Alpha in units of 0.1' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='gamma <0-62>'>
|
||||
<params>
|
||||
<param name='gamma' doc='Gamma parameter for MS power control in units of dB (see TS 05.08)' />
|
||||
<param name='<0-62>' doc='Gamma in even unit of dBs' />
|
||||
</params>
|
||||
</command>
|
||||
<command id='end'>
|
||||
<params>
|
||||
<param name='end' doc='End current mode and change to enable mode' />
|
||||
</params>
|
||||
</command>
|
||||
</node>
|
||||
</vtydoc>
|
|
@ -0,0 +1,41 @@
|
|||
# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/
|
||||
# Makefile from BitBake/OpenEmbedded manuals
|
||||
|
||||
EXTRA_DEPS = gen-sgsn-vty-docbook
|
||||
|
||||
topdir = .
|
||||
sgsn_reference = $(topdir)/osmosgsn-vty-reference.xml
|
||||
manuals = $(sgsn_reference)
|
||||
# types = pdf txt rtf ps xhtml html man tex texi dvi
|
||||
# types = pdf txt
|
||||
types = $(docbooktotypes)
|
||||
docbooktotypes = pdf
|
||||
# htmlcssfile =
|
||||
# htmlcss =
|
||||
|
||||
TOPDIR := ..
|
||||
ASCIIDOCS := osmosgsn-usermanual
|
||||
|
||||
include $(TOPDIR)/build/Makefile.asciidoc.inc
|
||||
include $(TOPDIR)/build/Makefile.inc
|
||||
|
||||
osmosgsn-usermanual.pdf: chapters/*.adoc
|
||||
|
||||
clean:
|
||||
rm -rf $(cleanfiles)
|
||||
|
||||
gen-sgsn-vty-docbook: FORCE
|
||||
$(call command,xsltproc -o generated/combined1.xml \
|
||||
--stringparam with $(PWD)/../common/vty_additions.xml \
|
||||
$(MERGE_DOC) vty/sgsn_vty_reference.xml, \
|
||||
XSLTPROC,Merging Common VTY)
|
||||
$(call command,xsltproc -o generated/combined2.xml \
|
||||
--stringparam with $(PWD)/../common/ns_vty_additions.xml \
|
||||
$(MERGE_DOC) generated/combined1.xml, \
|
||||
XSLTPROC,Merging Common NS VTY)
|
||||
$(call command,xsltproc -o generated/combined3.xml \
|
||||
--stringparam with $(PWD)/vty/sgsn_vty_additions.xml \
|
||||
$(MERGE_DOC) generated/combined2.xml, \
|
||||
XSLTPROC,Merging SGSN VTY)
|
||||
$(call command,xsltproc ../vty_reference.xsl generated/combined3.xml > generated/docbook_vty.xml, \
|
||||
XSLTPROC,Converting SGSN VTY to DocBook)
|
|
@ -0,0 +1,163 @@
|
|||
== Configuring OsmoSGSN
|
||||
|
||||
Contrary to other network elements (like OsmoBSC, OsmoNITB), the
|
||||
OsmoSGSN has a relatively simple configuration.
|
||||
|
||||
On the one hand, this is primary because the PCU configuration happens
|
||||
from the BSC side.
|
||||
|
||||
On the other hand, it is because the Gb interface does not need an
|
||||
explicit configuration of all each PCU connecting to the SGSN. The
|
||||
administrator only has to ensure that the NS and BSSGP layer identities
|
||||
(NSEI, NSVCI, BVCI) are unique for each PCU connecting to the SGSN.
|
||||
|
||||
=== Configuring the Gp interface
|
||||
|
||||
The Gp interface is the GTP-C and GTP-U based interface between the SGSN
|
||||
and the GGSNs. It is implemented via UDP on well-known source and
|
||||
destination ports.
|
||||
|
||||
When a MS requests establishment of a PDP context, it specifies the APN
|
||||
(Access Point Name) to which the context shall be established. This APN
|
||||
determines which GGSN shall be used, and that in turn determines which
|
||||
external IP network the MS will be connected to.
|
||||
|
||||
There are two modes in which GGSNs can be configured:
|
||||
|
||||
. static GGSN/APN configuration
|
||||
. dynamic GGSN/APN configuration
|
||||
|
||||
==== Static GGSN/APN configuration
|
||||
|
||||
In this mode, there is a static list of GGSNs and APNs configured in
|
||||
OsmoSGSN via the VTY / config file.
|
||||
|
||||
This is a non-standard method outside of the 3GPP specifications for the
|
||||
SGSN, and is typically only used in private/small GPRS networks without
|
||||
any access to a GRX.
|
||||
|
||||
.Example: Static GGSN/APN configuration (single catch-all GGSN)
|
||||
----
|
||||
OsmoSGSN(config-sgsn)# gtp local-ip 172.0.0.1 <1>
|
||||
OsmoSGSN(config-sgsn)# ggsn 0 remote-ip 127.0.0.2 <2>
|
||||
OsmoSGSN(config-sgsn)# ggsn 0 gtp-version 1 <3>
|
||||
OsmoSGSN(config-sgsn)# apn * ggsn 0 <4>
|
||||
----
|
||||
<1> Configure the local IP address at the SGSN used for Gp/GTP
|
||||
<2> Specify the remote IP address of the GGSN (for GGSN 0)
|
||||
<3> Specify the GTP protocol version used for GGSN 0
|
||||
<4> Route all APN names to GGSN 0
|
||||
|
||||
|
||||
==== Dynamic GGSN/APN configuration
|
||||
|
||||
In this mode, the SGSN will use a DNS-based method to perform the lookup
|
||||
from the APN (as specified by the MS) towards the GGSN IP address.
|
||||
|
||||
This is the official method as per the 3GPP specifications for the SGSN,
|
||||
and what is used on GRX.
|
||||
|
||||
.Example: Dynamic GGSN/APN configuration
|
||||
----
|
||||
OsmoSGSN(config-sgsn)# gtp local-ip 192.168.0.11 <1>
|
||||
OsmoSGSN(config-sgsn)# ggsn dynamic <2>
|
||||
OsmoSGSN(config-sgsn)# grx-dns-add 1.2.3.4 <3>
|
||||
----
|
||||
<1> Configure the local IP address at the SGSN used for Gp/GTP
|
||||
<2> Enable the dynamic GGSN resolving mode
|
||||
<3> Specify the IP address of a DNS server for APN resolution
|
||||
|
||||
|
||||
=== Subscriber Configuration
|
||||
|
||||
As opposed to OsmoNITB, OsmoSGSN does not feature a built-in HLR.
|
||||
|
||||
It can thus operate only in the following two modes:
|
||||
|
||||
. Accessing an external HLR (or HLR gateway) via the GSUP protocol
|
||||
. Accepting subscribers based on internal ACL (access control list)
|
||||
|
||||
==== Accessing an external HLR via GSUP
|
||||
|
||||
The non-standard GSUP protocol was created to provide OsmoSGSN with
|
||||
access to an external HLR while avoiding the complexities of the
|
||||
TCAP/MAP protocol stack commonly used by HLRs.
|
||||
|
||||
A custom HLR could either directly implement GSUP, or an external gateway
|
||||
can be used to convert GSUP to the respective MAP operations.
|
||||
|
||||
The primitives/operations of GSUP are modelled to have a 1:1
|
||||
correspondence to their MAP counterparts. However, the encoding is much
|
||||
simplified by use of a binary TLV encoding similar to Layer 3 of
|
||||
GSM/GPRS.
|
||||
|
||||
GSUP performs a challenge-response authentication protocol called OAP,
|
||||
which uses the standard MILEAGE algorithm for mutual authentication
|
||||
between OsmoSGSN and the HLR/HLR-GW.
|
||||
|
||||
[[sgsn-ex-gsup]]
|
||||
.Example: Using an external HLR via GSUP
|
||||
----
|
||||
OsmoSGSN(config-sgsn)# gsup remote-ip 2.3.4.5 <1>
|
||||
OsmoSGSN(config-sgsn)# gsup remote-port 10000 <2>
|
||||
OsmoSGSN(config-sgsn)# gsup oap-k 000102030405060708090a0b0c0d0e0f <3>
|
||||
OsmoSGSN(config-sgsn)# gsup oap-opc 101112131415161718191a1b1c1d1e1f <4>
|
||||
----
|
||||
<1> Configure the IP address of the (remote) HLR or HLR-GW
|
||||
<2> Configure the TCP port of the (remote) HLR or HLR-GW
|
||||
<3> Specify the OAP shared key
|
||||
<4> Specify the OAP shared OPC
|
||||
|
||||
|
||||
=== CDR configuration
|
||||
|
||||
OsmoSGSN can write a text log file containing CDR (call data records),
|
||||
which are commonly used for accounting/billing purpose.
|
||||
|
||||
.Example: CDR configuration
|
||||
----
|
||||
OsmoSGSN(config-sgsn)# cdr filename /var/log/osmosgsn.cdr
|
||||
OsmoSGSN(config-sgsn)# cdr interval 600 <1>
|
||||
----
|
||||
<1> Periodically log existing PDP contexts every 600 seconds (10 min)
|
||||
|
||||
The CDR file is a simple CSV file including a header line naming the
|
||||
individual fields of each CSV line.
|
||||
|
||||
[[sgsn-cdr]]
|
||||
.Descripton of CSV fields in OsmoSGSN CDR file
|
||||
[options="header",cols="15%,85%"]
|
||||
|===
|
||||
|timestamp|Timestamp in YYYYMMDDhhmmssXXX where XXX are milli-seconds
|
||||
|imsi|IMSI causing this CDR
|
||||
|imei|IMEI causing this CDR
|
||||
|msisdn|MSISDN causing this CDR (if known)
|
||||
|cell_id|Cell ID in which the MS was registered last
|
||||
|lac|Location Area Code in which the MS was registered last
|
||||
|hlr|HLR of the subscriber
|
||||
|event|Possible events are explained below in <<sgsn-cdr-evt>>
|
||||
|pdp|
|
||||
|pdp_duration|duration of the PDP context so far
|
||||
|ggsn_addr|GGSN related to the PDP context
|
||||
|sgsn_addr|SGSN related to the PDP context
|
||||
|apni|APN identifier of the PDP context
|
||||
|eua_addr|IP address allocated to the PDP context
|
||||
|vol_in|Number of bytes in MO direction
|
||||
|vol_out|Number of bytes in MT direction
|
||||
|charging_id|Related charging ID
|
||||
|===
|
||||
|
||||
[[sgsn-cdr-event]]
|
||||
.Description of OsmoSGSN CDR Events
|
||||
[options="header",cols="15%,85%"]
|
||||
|===
|
||||
|Event|Description
|
||||
|attach|GMM ATTACH COMPLETE about to be sent to MS
|
||||
|update|GMM ROUTING AREA UPDATE COMPLETE about to be sent to MS
|
||||
|detach|GMM DETACH REQUEST received from MS
|
||||
|free|Release of the MM context memory
|
||||
|pdp-act|GTP CREATE PDP CONTEXT CONFIRM received from GGSN
|
||||
|pdp-deact|GTP DELETE PDP CONTEXT CONFIRM received from GGSN
|
||||
|pdp-terminate|Forced PDP context termination during MM context release
|
||||
|pdp-free|Release of the PDP context memory
|
||||
|===
|
|
@ -0,0 +1,592 @@
|
|||
[[gsup]]
|
||||
== GPRS Subscriber Update Protocol
|
||||
|
||||
=== General
|
||||
|
||||
This chapter describes the remote protocol that is used by the SGSN to update
|
||||
and manage the local subscriber list. The protocol and the messages are
|
||||
designed after the corresponding MAP messages (see 3GPP TS 09.02) with the
|
||||
following differences:
|
||||
|
||||
* The encoding uses TLV structures instead of ASN.1 encodings
|
||||
* Segmentation is not used
|
||||
|
||||
For more information, see the specification of the Gr interface (3GPP TS 03.60).
|
||||
|
||||
=== Connection
|
||||
|
||||
The protocol expects that a reliable, ordered, packet boundaries preserving
|
||||
connection is used (e.g. IPA over TCP). The remote peer is either a service
|
||||
that understands the protocol natively or a wrapper service that maps the
|
||||
messages to/from real MAP messages that can be used to directly communicate
|
||||
with an HLR.
|
||||
|
||||
=== Using IPA
|
||||
|
||||
By default, the following identifiers should be used:
|
||||
|
||||
* IPA Stream ID: 0xEE (OSMO)
|
||||
* IPA OSMO protocol extension: 0x05
|
||||
|
||||
For more information about the IPA multiplex, please see the 'OsmoBTS
|
||||
Abis/IP Specifiation'.
|
||||
|
||||
=== Procedures
|
||||
|
||||
==== Authentication management
|
||||
|
||||
The SGSN sends a SEND_AUTHENTICATION_INFO_REQ message containing the MS's IMSI
|
||||
to the peer. On errors, especially if authentication info is not availabe for
|
||||
that IMSI, the peer returns a SEND_AUTHENTICATION_INFO_ERR message. Otherwise
|
||||
the peer returns a SEND_AUTHENTICATION_INFO_RES message. If this message
|
||||
contains at least one authentication tuple, the SGSN replaces all tuples that
|
||||
are assigned to the subscriber. If the message doesn't contain any tuple the
|
||||
SGSN may reject the Attach Request. (see 3GPP TS 09.02, 25.5.6)
|
||||
|
||||
==== Location Updating
|
||||
|
||||
The SGSN sends a UPDATE_LOCATION_REQ to the peer. If the request is denied by
|
||||
the network, the peer returns an UPDATE_LOCATION_ERR message to the SGSN.
|
||||
Otherwise the peer returns an UPDATE_LOCATION_RES message containing all
|
||||
information fields that shall be inserted into the subscriber record. If
|
||||
the 'PDP info complete' information element is set in the message, the SGSN
|
||||
clears existing PDP information fields in the subscriber record first.
|
||||
(see 3GPP TS 09.02, 19.1.1.8)
|
||||
|
||||
...
|
||||
|
||||
=== Message Format
|
||||
|
||||
==== General
|
||||
|
||||
Every message is based on the following message format
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|===
|
||||
|
||||
If a numeric range is indicated in the 'presence' column, multiple information
|
||||
elements with the same tag may be used in sequence. The information elements
|
||||
shall be sent in the given order. Nevertheless after the generic part the
|
||||
receiver shall be able to received them in any order. Unknown IE shall be
|
||||
ignored.
|
||||
|
||||
==== Send Authentication Info Request
|
||||
|
||||
Direction: SGSN -> Network peer
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|===
|
||||
|
||||
==== Send Authentication Info Error
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|02|Cause|<<gsup-ie-cause>>|M|TLV|3
|
||||
|===
|
||||
|
||||
==== Send Authentication Info Response
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|03|Auth Tuple|<<gsup-ie-authtuple>>|0-5|TLV|36
|
||||
|===
|
||||
|
||||
==== Update Location Request
|
||||
|
||||
Direction: SGSN -> Network peer
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|===
|
||||
|
||||
==== Update Location Error
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|02|Cause|<<gsup-ie-cause>>|M|TLV|3
|
||||
|===
|
||||
|
||||
==== Update Location Result
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|08|MSISDN|<<gsup-ie-msisdn>>|O|TLV|0-9
|
||||
|09|HLR Number|<<gsup-ie-hlr>>|O|TLV|0-9
|
||||
|04|PDP info complete|<<gsup-ie-empty>>|O|TLV|2
|
||||
|05|PDP info|<<gsup-ie-pdpinfo>>|1-10|TLV|
|
||||
|===
|
||||
|
||||
If the PDP info complete IE is present, the old PDP info list shall be cleared.
|
||||
|
||||
==== Location Cancellation Request
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|06|Cancellation type|<<gsup-ie-canctype>>|O|TLV|3
|
||||
|===
|
||||
|
||||
==== Location Cancellation Result
|
||||
|
||||
Direction: SGSN -> Network peer
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|===
|
||||
|
||||
==== Purge MS Request
|
||||
|
||||
Direction: SGSN -> Network peer
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|09|HLR Number|<<gsup-ie-hlr>>|M|TLV|0-9
|
||||
|===
|
||||
|
||||
==== Purge MS Error
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|02|Cause|<<gsup-ie-cause>>|M|TLV|3
|
||||
|===
|
||||
|
||||
==== Purge MS Result
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|07|Freeze P-TMSI|<<gsup-ie-empty>>|M|TLV|2
|
||||
|===
|
||||
|
||||
==== Insert Subscriber Data Request
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|04|PDP info complete|<<gsup-ie-empty>>|M|TLV|2
|
||||
|05|PDP info|<<gsup-ie-pdpinfo>>|0-10|TLV|
|
||||
|===
|
||||
|
||||
If the PDP info complete IE is present, the old PDP info list shall be cleared.
|
||||
|
||||
==== Insert Subscriber Data Error
|
||||
|
||||
Direction: SGSN -> Network peer
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|02|Cause|<<gsup-ie-cause>>|M|TLV|3
|
||||
|===
|
||||
|
||||
==== Insert Subscriber Data Result
|
||||
|
||||
Direction: SGSN -> Network peer
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|===
|
||||
|
||||
==== Delete Subscriber Data Request
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|10|PDP context id|<<gsup-ie-pdpinfo>> (no conditional IE)|0-10|TLV|
|
||||
|===
|
||||
|
||||
==== Delete Subscriber Data Error
|
||||
|
||||
Direction: SGSN -> Network peer
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|02|Cause|<<gsup-ie-cause>>|M|TLV|3
|
||||
|===
|
||||
|
||||
==== Delete Subscriber Data Result
|
||||
|
||||
Direction: Network peer -> SGSN
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<gsup-ie-msgtype>>|M|V|1
|
||||
|01|IMSI|<<gsup-ie-imsi>>|M|TLV|2-10
|
||||
|===
|
||||
|
||||
=== Information Elements
|
||||
|
||||
[[gsup-ie-msgtype]]
|
||||
==== Message Type
|
||||
|
||||
[options="header",cols="10%,90%"]
|
||||
|===
|
||||
|Type|Description
|
||||
|0x04|Update Location Request
|
||||
|0x05|Update Location Error
|
||||
|0x06|Update Location Result
|
||||
|0x08|Send Auth Info Request
|
||||
|0x09|Send Auth Info Error
|
||||
|0x0a|Send Auth Info Result
|
||||
|0x0c|Purge MS Request
|
||||
|0x0d|Purge MS Error
|
||||
|0x0e|Purge MS Result
|
||||
|0x10|Insert Subscriber Data Request
|
||||
|0x11|Insert Subscriber Data Error
|
||||
|0x12|Insert Subscriber Data Result
|
||||
|0x14|Delete Subscriber Data Request
|
||||
|0x15|Delete Subscriber Data Error
|
||||
|0x16|Delete Subscriber Data Result
|
||||
|0x1c|Location Cancellation Request
|
||||
|0x1d|Location Cancellation Error
|
||||
|0x1e|Location Cancellation Result
|
||||
|===
|
||||
|
||||
[[gsup-ie-ipaddr]]
|
||||
==== IP Address
|
||||
|
||||
The value part is encoded like in the Packet data protocol address IE defined
|
||||
in 3GPP TS 04.08, Chapter 10.5.6.4. PDP type organization must be set to
|
||||
'IETF allocated address'.
|
||||
|
||||
[[gsup-ie-pdpinfo]]
|
||||
==== PDP Info
|
||||
|
||||
This is a container for information elements describing a single PDP.
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |PDP Info IEI|<<gsup-iei>>|M|V|1
|
||||
| |Length of PDP Info IE||M|V|1
|
||||
|10|PDP Context ID|<<gsup-ie-pdpctxid>>|C|TLV|3
|
||||
|11|PDP Type|<<gsup-ie-pdptype>>|C|TLV|4
|
||||
|12|Access Point Name|3GPP TS 04.08, Ch. 10.5.6.1|C|TLV|3-102
|
||||
|13|Quality of Service|<<gsup-ie-qos>>|O|TLV|1-20
|
||||
|===
|
||||
|
||||
The conditional IE are mandantory unless mentioned otherwise.
|
||||
|
||||
[[gsup-ie-pdptype]]
|
||||
==== PDP Type
|
||||
|
||||
The PDP type value consists of 2 octets that are encoded like octet 4-5 of the
|
||||
End User Address defined in 3GPP TS 09.60, 7.9.18.
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP type IEI
|
||||
7: Res
|
||||
8-15: Length (2)
|
||||
16-19: Spare
|
||||
20-23: PDP type org
|
||||
24-31: PDP type number
|
||||
}
|
||||
----
|
||||
|
||||
The spare bits are left undefined. While 09.60 defines them as '1 1 1 1', there
|
||||
are MAP traces where these bits are set to '0 0 0 0'. So the receiver shall
|
||||
ignore these bits.
|
||||
|
||||
Examples:
|
||||
|
||||
* IPv4: PDP type org: 1 (IETF), PDP type number: 0x21
|
||||
* IPv6: PDP type org: 1 (IETF), PDP type number: 0x57
|
||||
|
||||
[[gsup-ie-pdpctxid]]
|
||||
==== PDP Context ID
|
||||
|
||||
The PDP type context ID IE consists of a single integer byte wrapped in
|
||||
a TLV.
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP context ID IEI
|
||||
7: Res
|
||||
8-15: Length (1)
|
||||
16-23: PDP Context ID
|
||||
}
|
||||
----
|
||||
|
||||
[[gsup-ie-authtuple]]
|
||||
==== Auth tuple
|
||||
|
||||
This is a container for information elements describing a single authentication
|
||||
tuple.
|
||||
|
||||
[options="header",cols="5%,20%,45%,10%,10%,10%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Auth Tuple IEI|<<gsup-iei>>|M|V|1
|
||||
| |Length of Auth Tuple IE||M|V|1
|
||||
|20|RAND|<<gsup-ie-rand>>|M|TLV|18
|
||||
|21|SRES|<<gsup-ie-sres>>|M|TLV|6
|
||||
|22|Kc|<<gsup-ie-kc>>|M|TLV|10
|
||||
|===
|
||||
|
||||
[[gsup-ie-rand]]
|
||||
==== RAND
|
||||
|
||||
The 16-byte Random Challenge of the GSM Authentication Algorithm.
|
||||
|
||||
[[gsup-ie-sres]]
|
||||
==== SRES
|
||||
|
||||
The 4-byte Authentication Result of the GSM Authentication Algorithm.
|
||||
|
||||
[[gsup-ie-kc]]
|
||||
==== Kc
|
||||
|
||||
The 8-byte Encryption Key of the GSM Authentication and Key Agreemnt
|
||||
Algorithm.
|
||||
|
||||
[[gsup-ie-canctype]]
|
||||
==== Cancellation Type
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP type IEI
|
||||
7: Res
|
||||
8-15: Length (1)
|
||||
16-23: Canc. Type Nr.
|
||||
}
|
||||
----
|
||||
|
||||
.Cancellation Type Number
|
||||
[options="header",cols="10%,90%"]
|
||||
|===
|
||||
|Number|Description
|
||||
|0x00|Update Procedure
|
||||
|0x01|Subscription Withdrawn
|
||||
|===
|
||||
|
||||
[[gsup-iei]]
|
||||
==== IE Identifier (informational)
|
||||
|
||||
These are the standard values for the IEI. See the message definitions for the
|
||||
IEI that shall be used for the encoding.
|
||||
|
||||
.GSUP IE Identifiers
|
||||
[options="header",cols="15%,35%,50%"]
|
||||
|===
|
||||
|IEI|Info Element|Type / Encoding
|
||||
|0x01|IMSI|Mobile Identity, 3GPP TS 04.08 Ch. 10.5.1.4
|
||||
|0x02|Cause|<<gsup-ie-cause>>
|
||||
|0x03|Auth Tuple|<<gsup-ie-authtuple>>
|
||||
|0x04|PDP Info Compl|<<gsup-ie-empty>>
|
||||
|0x05|PDP Info|<<gsup-ie-pdpinfo>>
|
||||
|0x06|Cancel Type|<<gsup-ie-canctype>>
|
||||
|0x07|Freeze P-TMSI|<<gsup-ie-empty>>
|
||||
|0x08|MSISDN|ISDN-AddressString/octet, <<gsup-ie-msisdn>>
|
||||
|0x09|HLR Number|<<gsup-ie-hlr>>
|
||||
|0x10|PDP Context ID|<<gsup-ie-pdpctxid>>
|
||||
|0x11|PDP Type|<<gsup-ie-pdptype>>
|
||||
|0x12|QoS|<<gsup-ie-qos>>
|
||||
|0x20|RAND|<<gsup-ie-rand>>
|
||||
|0x21|SRES|<<gsup-ie-sres>>
|
||||
|0x22|Kc|<<gsup-ie-kc>>
|
||||
|===
|
||||
|
||||
[[gsup-ie-empty]]
|
||||
==== Empty field
|
||||
|
||||
This is used for flags, if and only if this IE is present, the flag is set.
|
||||
The semantics depend on the IEI and the context.
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP type IEI
|
||||
7: Res
|
||||
8-15: Length (0)
|
||||
}
|
||||
----
|
||||
|
||||
[[gsup-ie-imsi]]
|
||||
==== IMSI
|
||||
|
||||
The IMSI is encoded like in octet 4-N of the Called Party BCD Number
|
||||
defined in 3GPP TS 04.08, 10.5.4.7.
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP type IEI
|
||||
7: Res
|
||||
8-15: Length of IE content
|
||||
16-19: Digit 1
|
||||
20-23: Digit 2
|
||||
24-27: Digit ...
|
||||
28-31: Digit N
|
||||
32-39: see Note
|
||||
}
|
||||
----
|
||||
|
||||
NOTE: Either '1 1 1 1 | Number digit N' (N odd) or 'Number digit N |
|
||||
Number digit N-1' (N even), where N is the number of digits.
|
||||
|
||||
[[gsup-ie-msisdn]]
|
||||
==== ISDN-AddressString / MSISDN / Called Party BCD Number
|
||||
|
||||
The MSISDN is encoded as an ISDN-AddressString in 3GPP TS 09.02 and Called Party
|
||||
BCD Number in 3GPP TS 04.08. It will be stored by the SGSN and then passed as is
|
||||
to the GGSN during the activation of the primary PDP Context.
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP type IEI
|
||||
7: Res
|
||||
8-15: Length of IE content
|
||||
16-19: NPI
|
||||
20-22: TON
|
||||
23: ext
|
||||
24-27: Digit 1
|
||||
28-31: Digit 2
|
||||
32-35: Digit ...
|
||||
36-39: Digit N
|
||||
}
|
||||
----
|
||||
|
||||
[[gsup-ie-qos]]
|
||||
==== Quality of Service Subscribed Service
|
||||
|
||||
This encodes the subscribed QoS of a subscriber. It will be used by the
|
||||
SGSN during the PDP Context activation. If the length of the QoS data
|
||||
is 3 (three) octets it is assumed that these are octets 3-5 of the TS
|
||||
3GPP TS 24.008 Quality of Service Octets. If it is more than three then
|
||||
then it is assumed that the first octet is the Allocation/Retention
|
||||
Priority and the reset are encoded as octets 3-N of 24.008.
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP type IEI
|
||||
7: Res
|
||||
8-15: Length of IE content
|
||||
16-23: Payload
|
||||
}
|
||||
----
|
||||
|
||||
[[gsup-ie-hlr]]
|
||||
==== HLR Number encoded as 3GPP TS 09.02 ISDN-AddressString
|
||||
|
||||
The HLR Number is encoded as an ISDN-AddressString in 3GPP TS 09.02. It
|
||||
will be stored by the SGSN can be used by the CDR module to keep a
|
||||
record.
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-6: PDP type IEI
|
||||
7: Res
|
||||
8-15: Length of IE content
|
||||
16-19: NPI
|
||||
20-22: TON
|
||||
23: ext
|
||||
24-27: Digit 1
|
||||
28-31: Digit 2
|
||||
32-35: Digit ...
|
||||
36-39: Digit N
|
||||
}
|
||||
----
|
||||
|
||||
[[gsup-ie-cause]]
|
||||
==== Cause
|
||||
|
||||
This IE shall be encoded according to the 'GMM Cause' as described in
|
||||
Chapter 10.5.5.14 of 3GPP TS 04.08.
|
|
@ -0,0 +1,126 @@
|
|||
[[chapter_introduction]]
|
||||
== Overview
|
||||
|
||||
[[intro_overview]]
|
||||
=== About OsmoSGSN
|
||||
|
||||
OsmoSGSN is the Osmocom implementation of the GPRS SGSN (Serving Gprs
|
||||
Support Node) element inside the GPRS network. The SGSN plays a similar
|
||||
central function to the GPRS network as the MSC plays in the GSM
|
||||
network.
|
||||
|
||||
The SGSN is connected on the downlink side to Gb interfaces of the BSS,
|
||||
specifically the PCU inside the BSS. The SGSN is further connected by
|
||||
the GTP protocol to the GGSN which terminates the tunnels towards the
|
||||
external packet data network (e.g. IPv4).
|
||||
|
||||
OsmoSGSN supports both a PCU that is co-located with(in) the BTS, as
|
||||
well as a PCU that is co-located with(in) the BSC. In combination with
|
||||
OsmoNITB/OsmoBSC/OsmoBTS, the PCU is co-located within the BTS.
|
||||
|
||||
[[fig-gprs-pcubts]]
|
||||
.GPRS network architecture with PCU in BTS
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir=LR;
|
||||
MS0 [label="MS"]
|
||||
MS1 [label="MS"]
|
||||
MS0->BTS [label="Um"]
|
||||
MS1->BTS [label="Um"]
|
||||
BTS->BSC [label="Abis"]
|
||||
BSC->MSC [label="A"]
|
||||
BTS->PCU [label="pcu_sock"]
|
||||
PCU->SGSN [label="Gb"]
|
||||
SGSN->GGSN [label="GTP"]
|
||||
}
|
||||
----
|
||||
|
||||
=== Software Components
|
||||
|
||||
OsmoNITB contains a variety of different software components, which
|
||||
we'll quickly describe in this section.
|
||||
|
||||
==== Gb Implementation
|
||||
|
||||
OsmoSGSN implements the ETSI/3GPP specified Gb interface, including TS
|
||||
08.16 (NS), TS 08.18 (BSSGP) and TS 08.64 (LLC) protocols. As transport
|
||||
layers for NS, it supports NS/IP (NS encapsulated in UDP/IP), as well as
|
||||
NS/FR/GRE/IP. The latter is provided in order to use a Router with
|
||||
Ethernet and Frame Relay interface to convert to actual physical Frame
|
||||
Relay medium, which is not directly supported by OsmoSGSN.
|
||||
|
||||
The actual Gb Implementation is part of the libosmogb library, which is
|
||||
in turn part of the libosmocore software package. This allows the same
|
||||
Gb implementation to be used from osmo-pcu, osmo-gbproxy as well as
|
||||
OsmoSGSN.
|
||||
|
||||
|
||||
==== GTP Implementation
|
||||
|
||||
OsmoSGSN uses the libgtp implementation originating from OpenGGSN. It
|
||||
supports both GTPv0 and GTPv1.
|
||||
|
||||
|
||||
==== GMM Implementation
|
||||
|
||||
The GPRS Mobility Management implementation is quite simplistic at this
|
||||
point. It supports the GPRS ATTACH and GPRS ROUTING AREA UPDATE
|
||||
procedures, as well as GPRS ATTACH and GPRS DETACH.
|
||||
|
||||
However, as the SGSN currently does not implement any type of HLR
|
||||
access, it is not able to authenticate a subscriber or even check if the
|
||||
subscriber exists at all. As such, all non-roaming subscribes are
|
||||
allowed to attach to OsmoSGSN. Non-roaming means that the first 5
|
||||
digits of the IMSI must match the MCC and MNC of the cell that the
|
||||
subscriber is registering to.
|
||||
|
||||
|
||||
==== LLC Implementation
|
||||
|
||||
The LLC (Logical Link Control) implementation of OsmoSGSN only supports
|
||||
non-acknowledged mode, as this is the most common use case in real-world
|
||||
GPRS networks.
|
||||
|
||||
Furthermore, it does not support IP header nor payload compression at
|
||||
this point. Addition of those features is subject to customer demand or
|
||||
user/customer contributions.
|
||||
|
||||
The LLC implementation does support LLC encryption. However, as no HLR
|
||||
access is implemented yet, there is no way to enable/configure
|
||||
per-subscriber specific keys.
|
||||
|
||||
|
||||
==== Session Management Implementation
|
||||
|
||||
The session management procedures ACTIVATE PDP CONTEXT and DEACTIVATE
|
||||
PDP CONTEXT are supported. However, no MODIFY PDP CONTEXT and no
|
||||
Network-initiated PDP context activation is possible. This is again
|
||||
covering the predominant use cases and configurations in GPRS real-world
|
||||
networks while skipping the more esoteric features.
|
||||
|
||||
Multiple PDP contexts can be attached by a single MS.
|
||||
|
||||
Currently, all PDP contexts are routed to the same GGSN, irrespective of
|
||||
the APN used/configured in the MS. This is sufficient (and actually
|
||||
desirable) for small autonomous networks, but of course not suitable for
|
||||
real networks in roaming scenarios. Please contact sysmocom in case you
|
||||
require additional features such as DNS-based APN resolving.
|
||||
|
||||
=== Limitations
|
||||
|
||||
At the time of writing, OsmoSGSN still has a number of limitations,
|
||||
which are a result of the demand-driven Open Source development model.
|
||||
If you require any of those features, please consider implementing and
|
||||
contributing them, or contracting the existing OsmoSGSN developers for
|
||||
performing that work.
|
||||
|
||||
Known Limitations include:
|
||||
|
||||
* No LLC encryption support
|
||||
* No interface to the OsmoNITB HLR
|
||||
* No paging coordination between SGSN and MSC
|
||||
* No SMS over Ps support
|
||||
* No IuPS interface for 3G (in progress)
|
||||
* No IP header compression
|
||||
* No payload compression
|
|
@ -0,0 +1,35 @@
|
|||
== Running OsmoSGSN
|
||||
|
||||
The OsmoSGSN executable (`osmo-sgsn`) offers the following command-line
|
||||
options:
|
||||
|
||||
|
||||
=== SYNOPSIS
|
||||
|
||||
*osmo-sgsn* [-h|-V] [-d 'DBGMASK'] [-D] [-c 'CONFIGFILE'] [-s] [-e 'LOGLEVEL']
|
||||
|
||||
|
||||
=== 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 <<logging>> 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 `osmo_sgsn.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 <<logging>>
|
||||
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
|
||||
<<logging>> for more information.
|
|
@ -0,0 +1,48 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1</revnumber>
|
||||
<date>January 13, 2013</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Initial version.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2</revnumber>
|
||||
<date>February 2016</date>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<revremark>
|
||||
Conversion to asciidoc, removal of sysmoBTS specific parts.
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Harald</firstname>
|
||||
<surname>Welte</surname>
|
||||
<email>hwelte@sysmocom.de</email>
|
||||
<authorinitials>HW</authorinitials>
|
||||
<affiliation>
|
||||
<shortaffil>sysmocom</shortaffil>
|
||||
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
|
||||
<jobtitle>Managing Director</jobtitle>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2013-2016</year>
|
||||
<holder>sysmocom - s.f.m.c. GmbH</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
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 no Invariant Sections, no Front-Cover Texts,
|
||||
and no Back-Cover Texts. A copy of the license is included in
|
||||
the section entitled "GNU Free Documentation License".
|
||||
</para>
|
||||
</legalnotice>
|
|
@ -0,0 +1,32 @@
|
|||
OsmoSGSN User Manual
|
||||
====================
|
||||
Harald Welte <hwelte@sysmocom.de>
|
||||
|
||||
|
||||
include::../common/chapters/preface.adoc[]
|
||||
|
||||
include::chapters/overview.adoc[]
|
||||
|
||||
include::chapters/running.adoc[]
|
||||
|
||||
include::../common/chapters/vty.adoc[]
|
||||
|
||||
include::../common/chapters/logging.adoc[]
|
||||
|
||||
include::chapters/configuration.adoc[]
|
||||
|
||||
include::../common/chapters/gb.adoc[]
|
||||
|
||||
include::../common/chapters/control_if.adoc[]
|
||||
|
||||
include::../common/chapters/oap.adoc[]
|
||||
|
||||
include::chapters/gsup.adoc[]
|
||||
|
||||
include::../common/chapters/port_numbers.adoc[]
|
||||
|
||||
include::../common/chapters/bibliography.adoc[]
|
||||
|
||||
include::../common/chapters/glossary.adoc[]
|
||||
|
||||
include::../common/chapters/gfdl.adoc[]
|
|
@ -0,0 +1,44 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!--
|
||||
ex:ts=2:sw=42sts=2:et
|
||||
-*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
||||
-->
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
|
||||
"http://www.docbook.org/xml/5.0/dtd/docbook.dtd" [
|
||||
<!ENTITY chapter-vty SYSTEM "../common/chapters/vty.xml" >
|
||||
<!ENTITY sections-vty SYSTEM "generated/docbook_vty.xml" >
|
||||
]>
|
||||
|
||||
<book>
|
||||
<info>
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1</revnumber>
|
||||
<date>13th January 2013</date>
|
||||
<authorinitials>hw</authorinitials>
|
||||
<revremark>Initial</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v2</revnumber>
|
||||
<date>5th March 2014</date>
|
||||
<authorinitials>hf</authorinitials>
|
||||
<revremark>Update to match osmo-bsc version 0.13.0-305</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<title>OsmoSGSN VTY Reference</title>
|
||||
|
||||
<copyright>
|
||||
<year>2013-2014</year>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>This work is copyright by <orgname>sysmocom - s.f.m.c. GmbH</orgname>. All rights reserved.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</info>
|
||||
|
||||
<!-- Main chapters-->
|
||||
&chapter-vty;
|
||||
</book>
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='21'>
|
||||
<child_of nodeid='4' />
|
||||
<name>SGSN Configuration Node</name>
|
||||
<description>Configure the remote GGSN, access-control and other
|
||||
attributes of the SGSN</description>
|
||||
<command id='gtp local-ip A.B.C.D'>
|
||||
<description>
|
||||
Configure the local IP address to which the SGSN should
|
||||
bind for the Gp interface (towards the GGSNs).
|
||||
|
||||
Please note that in case you would like to run the GGSN
|
||||
on the same machine as the SGSN, you can not run both on
|
||||
the same IP address. It is suggested to use 127.0.0.1
|
||||
for the SGSN and 127.0.0.2 for the GGSN in such
|
||||
situations.
|
||||
</description>
|
||||
</command>
|
||||
<command id='ggsn <0-255> remote-ip A.B.C.D'>
|
||||
<description>
|
||||
Configure a static GGSN with a given numeric identifier
|
||||
to use the specified remote IP address.
|
||||
</description>
|
||||
</command>
|
||||
<command id='ggsn <0-255> gtp-version (0|1)'>
|
||||
<description>
|
||||
Configure whether to use GTPv0 or GTPv1 towards the
|
||||
specified GSSN number.
|
||||
</description>
|
||||
</command>
|
||||
<command id='ggsn dynamic'>
|
||||
<description>
|
||||
Enable dynamic resolving of GGSNs based on DNS resolving
|
||||
the APN name like in a GRX-style setup. Changing this
|
||||
setting requires a re-start of the SGSN.
|
||||
</description>
|
||||
</command>
|
||||
<command id='grx-dns-add A.B.C.D'>
|
||||
<description>
|
||||
Use the specified IP address for DNS-resolving the AP
|
||||
names to GGSN IP addresses
|
||||
</description>
|
||||
</command>
|
||||
<command id='apn APNAME ggsn <0-255>'>
|
||||
<description>
|
||||
Map the given APN Name to the given GGSN number.
|
||||
</description>
|
||||
</command>
|
||||
<command id='apn APNAME imsi-prefx IMSIPRE ggsn <0-255>'>
|
||||
<description>
|
||||
Map the given APN Name to the given GGSN number _only_
|
||||
if the IMSI matches the given prefix.
|
||||
</description>
|
||||
</command>
|
||||
<command id='imsi-acl (add|del) IMSI'>
|
||||
<description>
|
||||
Add or delete the given IMSI to/from the global Access
|
||||
Control List.
|
||||
</description>
|
||||
</command>
|
||||
<command id='auth-policy (accept-all|closed|acl-only|remote)'>
|
||||
<description>
|
||||
Configure the Authorization policy of the SGSN. This
|
||||
setting determines which subscribers are permitted to
|
||||
register to the network.
|
||||
</description>
|
||||
</command>
|
||||
<command id='gsup remote-ip A.B.C.D'>
|
||||
<description>
|
||||
Set the IP address of the HLR (gateway) for the GSUP protocol.
|
||||
This setting only applies if auth-policy remote is used.
|
||||
</description>
|
||||
</command>
|
||||
<command id='gsup oap-id <0-65535>'>
|
||||
<description>
|
||||
Set the OAP client ID for authentication on the GSUP
|
||||
protocol.
|
||||
This setting only applies if auth-policy remote is used.
|
||||
</description>
|
||||
</command>
|
||||
<command id='gsup oap-k K'>
|
||||
<description>
|
||||
Set the OAP shared secret key K for authentication on
|
||||
the GSUP protocol.
|
||||
This setting only applies if auth-policy remote is used.
|
||||
</description>
|
||||
</command>
|
||||
<command id='gsup oap-opc OPC'>
|
||||
<description>
|
||||
Set the OAP shared secret OPC for authentication on the
|
||||
GSUP protocol.
|
||||
This setting only applies if auth-policy remote is used.
|
||||
</description>
|
||||
</command>
|
||||
<command id='access-point-name NAME'>
|
||||
<description>
|
||||
Globally allow the given APN name for all subscribers.
|
||||
</description>
|
||||
</command>
|
||||
<command id='cdr filename NAME'>
|
||||
<description>
|
||||
Set the file name for the call-data-record file,
|
||||
logging the data usage of each subscriber.
|
||||
</description>
|
||||
</command>
|
||||
<command id='cdr interval <1-2147483647>'>
|
||||
<description>
|
||||
Set the interval (in secodnds) for the call-data-record
|
||||
file.
|
||||
</description>
|
||||
</command>
|
||||
</node>
|
||||
</vtydoc>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,17 @@
|
|||
BUILDDIR = $(TOPDIR)/build
|
||||
|
||||
# prepend the document name with the version numbe suffix
|
||||
#DOCS_VER = $(foreach P, $(ASCIIDOCS), $(P)-v$(shell xmllint --recover --xpath "//revnumber[position()=last()]/text()" $(P)-docinfo.xml 2>/dev/null))
|
||||
#PDFS = $(DOCS_VER:%=%.pdf)
|
||||
|
||||
# generate list of PDFs that we're supposed to render
|
||||
ASCIIDOCPDFS = $(ASCIIDOCS:%=%.pdf)
|
||||
|
||||
ASCIIDOCSTYLE ?= $(BUILDDIR)/custom-dblatex.sty
|
||||
|
||||
cleanfiles += $(ASCIIDOCPDFS)
|
||||
|
||||
all: $(ASCIIDOCPDFS)
|
||||
|
||||
$(ASCIIDOCPDFS): %.pdf: %.adoc %-docinfo.xml $(ASCIIDOCSTYLE) $(TOPDIR)/common/chapters/*.adoc
|
||||
a2x -L --asciidoc-opts="-f $(BUILDDIR)/mscgen-filter.conf -f $(BUILDDIR)/diag-filter.conf" --dblatex-opts=" -s $(ASCIIDOCSTYLE)" -a docinfo $< || asciidoc -f $(BUILDDIR)/mscgen-filter.conf -f $(BUILDDIR)/diag-filter.conf $<
|
|
@ -0,0 +1,47 @@
|
|||
# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/
|
||||
# Makefile from BitBake/OpenEmbedded manuals
|
||||
|
||||
LIBOSMO_DIR := ~/source/gsm/libosmocore
|
||||
MERGE_DOC := $(LIBOSMO_DIR)/doc/vty/merge_doc.xsl
|
||||
UPLOAD_PATH := generic@sysmocom-downloads:documents
|
||||
|
||||
pdfs = $(patsubst %.xml,%.pdf,$(manuals))
|
||||
lint = $(patsubst %.xml,%.xml-lint,$(manuals))
|
||||
|
||||
#cleanfiles = $(foreach i,$(types),$(topdir)/$(i))
|
||||
cleanfiles += $(pdfs) $(lint)
|
||||
|
||||
ifdef DEBUG
|
||||
dblatex_quiet =
|
||||
define command
|
||||
$(1)
|
||||
endef
|
||||
else
|
||||
dblatex_quiet = -q
|
||||
define command
|
||||
@echo $(2) $(3)
|
||||
@$(1)
|
||||
endef
|
||||
endif
|
||||
|
||||
all: $(types)
|
||||
|
||||
|
||||
$(types): FORCE
|
||||
|
||||
|
||||
pdf: $(pdfs) $(manuals)
|
||||
|
||||
|
||||
# Lint the file
|
||||
%.xml-lint: %.xml FORCE
|
||||
$(call command,xmllint --xinclude --postvalid --noout $<,XMLLINT,$<)
|
||||
|
||||
# Create a PDF file and lint it before
|
||||
%.pdf: %.xml %.xml-lint $(EXTRA_DEPS) FORCE
|
||||
$(call command,dblatex $(dblatex_quiet) -P draft.mode=no $<,DBLATEX,$<)
|
||||
|
||||
upload: $(pdfs)
|
||||
rsync -avz $(pdfs) $(UPLOAD_PATH)/
|
||||
|
||||
FORCE:
|
|
@ -0,0 +1,77 @@
|
|||
%%
|
||||
%% This style is derived from the docbook one.
|
||||
%%
|
||||
\NeedsTeXFormat{LaTeX2e}
|
||||
\ProvidesPackage{asciidoc}[2008/06/05 AsciiDoc DocBook Style]
|
||||
%% Just use the original package and pass the options.
|
||||
\RequirePackageWithOptions{docbook}
|
||||
|
||||
% Sidebar is a boxed minipage that can contain verbatim.
|
||||
% Changed shadow box to double box.
|
||||
\renewenvironment{sidebar}[1][0.95\textwidth]{
|
||||
\hspace{0mm}\newline%
|
||||
\noindent\begin{Sbox}\begin{minipage}{#1}%
|
||||
\setlength\parskip{\medskipamount}%
|
||||
}{
|
||||
\end{minipage}\end{Sbox}\doublebox{\TheSbox}%
|
||||
}
|
||||
|
||||
\usepackage{alltt}
|
||||
\usepackage{upquote}
|
||||
|
||||
\def\Company{sysmocom - s.f.m.c. GmbH}
|
||||
|
||||
\def\DBKcover{
|
||||
\ifthenelse{\equal{\DBKedition}{}}{\def\edhead{}}{\def\edhead{Ed. \DBKedition}}
|
||||
|
||||
% interligne double
|
||||
\setlength{\oldbaselineskip}{\baselineskip}
|
||||
\setlength{\baselineskip}{2\oldbaselineskip}
|
||||
\textsf{
|
||||
\vfill
|
||||
\begin{center}
|
||||
\includegraphics{../common/images/sysmocom.pdf}
|
||||
\ \\ %
|
||||
\huge{\Company}
|
||||
\end{center}
|
||||
\vspace{2.5cm}
|
||||
\begin{center}
|
||||
\includegraphics{../common/images/osmocom.pdf}
|
||||
\ \\ %
|
||||
\vspace{0.5cm}
|
||||
\huge{\textbf{\DBKtitle}}\\ %
|
||||
\ifx\DBKsubtitle\relax\else%
|
||||
\underline{\ \ \ \ \ \ \ \ \ \ \ }\\ %
|
||||
\ \\ %
|
||||
\huge{\textbf{\DBKsubtitle}}\\ %
|
||||
\fi
|
||||
\vspace*{2.5cm}
|
||||
\large{by \DBKauthor}
|
||||
\end{center}
|
||||
\vfill
|
||||
\setlength{\baselineskip}{\oldbaselineskip}
|
||||
\hspace{1cm}
|
||||
\vspace{1cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{p{7cm} p{7cm}}
|
||||
\Large{\DBKreference{} \edhead} & \\
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
}
|
||||
|
||||
% Format for the other pages
|
||||
%\newpage
|
||||
\setlength{\baselineskip}{\oldbaselineskip}
|
||||
}
|
||||
|
||||
% left footer
|
||||
\def\DBKpublisher{}
|
||||
|
||||
\def\maketitle{
|
||||
\DBKcover
|
||||
\DBKcopyright
|
||||
\DBKlegalblock
|
||||
\newpage
|
||||
\lfoot[]{\DBKcopyright}
|
||||
\DBKdomitete
|
||||
}
|
|
@ -0,0 +1,76 @@
|
|||
#
|
||||
# AsciiDoc seqdiag/blockdiag/nwdiag/packetdiag/actdiag filter configuration file.
|
||||
#
|
||||
|
||||
[seqdiag-filter-style]
|
||||
seqdiag-style=template="seqdiag-block",subs=(),posattrs=("style","target"),filter='seqdiag -o "{outdir={indir}}/{imagesdir=}{imagesdir?/}{target}" -T{format={basebackend-docbook!png}{basebackend-docbook?svg}} - && echo " "'
|
||||
|
||||
[blockdef-listing]
|
||||
template::[seqdiag-filter-style]
|
||||
|
||||
[paradef-default]
|
||||
template::[seqdiag-filter-style]
|
||||
|
||||
[seqdiag-block]
|
||||
template::[filter-image-pngsvg-blockmacro]
|
||||
|
||||
[filter-image-pngsvg-blockmacro]
|
||||
{target%}{counter2:target-number}
|
||||
{target%}{set2:target:{docname}__{target-number}.{format={basebackend-docbook!png}{basebackend-docbook?svg}}}
|
||||
|
|
||||
template::[image-blockmacro]
|
||||
|
||||
[blockdiag-filter-style]
|
||||
blockdiag-style=template="blockdiag-block",subs=(),posattrs=("style","target"),filter='blockdiag -o "{outdir={indir}}/{imagesdir=}{imagesdir?/}{target}" -T{format={basebackend-docbook!png}{basebackend-docbook?svg}} - && echo " "'
|
||||
|
||||
[blockdef-listing]
|
||||
template::[blockdiag-filter-style]
|
||||
|
||||
[paradef-default]
|
||||
template::[blockdiag-filter-style]
|
||||
|
||||
[blockdiag-block]
|
||||
template::[filter-image-pngsvg-blockmacro]
|
||||
|
||||
|
||||
|
||||
[actdiag-filter-style]
|
||||
actdiag-style=template="actdiag-block",subs=(),posattrs=("style","target"),filter='actdiag -o "{outdir={indir}}/{imagesdir=}{imagesdir?/}{target}" -T{format={basebackend-docbook!png}{basebackend-docbook?svg}} - && echo " "'
|
||||
|
||||
[blockdef-listing]
|
||||
template::[actdiag-filter-style]
|
||||
|
||||
[paradef-default]
|
||||
template::[actdiag-filter-style]
|
||||
|
||||
[actdiag-block]
|
||||
template::[filter-image-pngsvg-blockmacro]
|
||||
|
||||
|
||||
|
||||
[nwdiag-filter-style]
|
||||
nwdiag-style=template="nwdiag-block",subs=(),posattrs=("style","target"),filter='nwdiag -o "{outdir={indir}}/{imagesdir=}{imagesdir?/}{target}" -T{format={basebackend-docbook!png}{basebackend-docbook?svg}} - && echo " "'
|
||||
|
||||
[blockdef-listing]
|
||||
template::[nwdiag-filter-style]
|
||||
|
||||
[paradef-default]
|
||||
template::[nwdiag-filter-style]
|
||||
|
||||
[nwdiag-block]
|
||||
template::[filter-image-pngsvg-blockmacro]
|
||||
|
||||
|
||||
[packetdiag-filter-style]
|
||||
packetdiag-style=template="packetdiag-block",subs=(),posattrs=("style","target"),filter='packetdiag -o "{outdir={indir}}/{imagesdir=}{imagesdir?/}{target}" -T{format={basebackend-docbook!png}{basebackend-docbook?svg}} - && echo " "'
|
||||
|
||||
[blockdef-listing]
|
||||
template::[packetdiag-filter-style]
|
||||
|
||||
[paradef-default]
|
||||
template::[packetdiag-filter-style]
|
||||
|
||||
[packetdiag-block]
|
||||
template::[filter-image-pngsvg-blockmacro]
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
#! /usr/bin/env python
|
||||
"""Simple wrapper for filter programs which ensures that a blank
|
||||
is returned as output. The purpose is to silence the
|
||||
AsciiDoc warning "no output from filter".
|
||||
"""
|
||||
|
||||
import sys, subprocess
|
||||
|
||||
p = subprocess.Popen(sys.argv[1:])
|
||||
sys.stdout.write(' ') # To suppress asciidoc 'no output from filter' warnings.
|
||||
sys.exit(p.wait())
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
#
|
||||
# AsciiDoc mscgen filter configuration file.
|
||||
#
|
||||
|
||||
[mscgen-filter-style]
|
||||
mscgen-style=template="mscgen-block",subs=(),posattrs=("style","target"),filter='../build/filter-wrapper.py mscgen -o "{outdir={indir}}/{imagesdir=}{imagesdir?/}{target}" -T{format={basebackend-docbook!png}{basebackend-docbook?svg}} -'
|
||||
|
||||
[blockdef-listing]
|
||||
template::[mscgen-filter-style]
|
||||
|
||||
[paradef-default]
|
||||
template::[mscgen-filter-style]
|
||||
|
||||
[mscgen-block]
|
||||
template::[filter-image-pngsvg-blockmacro]
|
||||
|
||||
[filter-image-pngsvg-blockmacro]
|
||||
{target%}{counter2:target-number}
|
||||
{target%}{set2:target:{docname}__{target-number}.{format={basebackend-docbook!png}{basebackend-docbook?svg}}}
|
||||
|
|
||||
template::[image-blockmacro]
|
||||
|
|
@ -0,0 +1,244 @@
|
|||
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
|
||||
<node id='14'>
|
||||
<child_of nodeid='4' />
|
||||
<name>GSM Network Configuration</name>
|
||||
<description>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.</description>
|
||||
</node>
|
||||
<node id='15'>
|
||||
<child_of nodeid='14' />
|
||||
<name>BTS Configuration</name>
|
||||
<description>This is the configuration of a single BTS.</description>
|
||||
<command id='oml ip.access stream_id <0-255> line E1_LINE'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='is-connection-list (add|del) <0-2047> <0-2047> <0-255>'>
|
||||
<description>
|
||||
Only applies to Ericsson OML2000 based BTSs.
|
||||
</description>
|
||||
</command>
|
||||
<command id='con-connection-list (add|del) <1-255> <0-1023> deconcentrated'>
|
||||
<description>
|
||||
Only applies to Ericsson OML2000 based BTSs.
|
||||
</description>
|
||||
</command>
|
||||
<command id='con-connection-list (add|del) <1-255> <0-1023> tei <0-63>'>
|
||||
<description>
|
||||
Only applies to Ericsson OML2000 based BTSs.
|
||||
</description>
|
||||
</command>
|
||||
<command id='channel-descrption attach (0|1)'>
|
||||
<description>
|
||||
Configure whether the IMSI ATTACH (and DETACH) procedures
|
||||
shall be used by MS in this cell. The default should be enabled.
|
||||
</description>
|
||||
</command>
|
||||
<command id='ip.access rsl-ip A.B.C.D'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='base_station_id_code <0-63>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='training_sequence_code <0-7>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='si5 neighbor-list (add|del) arfcn <0-1023>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='neighbor-list (add|del) arfcn <0-1023>'>
|
||||
<description>
|
||||
Add or remove an ARFCN to/from the list of neighbor cells.
|
||||
This command is only available in manual neighbor-list mode.
|
||||
</description>
|
||||
</command>
|
||||
<command id='gprs network-control-order (nc0|nc1|nc2)'>
|
||||
<description>
|
||||
</description>
|
||||
</command>
|
||||
<command id='cell reselection offset <0-126>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='cell reselection hysteresis <0-14>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='ip.access unit_id <0-65534> <0-255>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='ms max power <0-40>'>
|
||||
<description>
|
||||
Configures the maximum transmit power (in dBm) that any MS may
|
||||
use within this cell.
|
||||
</description>
|
||||
</command>
|
||||
<command id='periodic location update <6-1530>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='cell barred (0|1)'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='rxlev access min <0-63>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='rach access-control-class (0|1|2|3|4|5|6|7|8|9|11|12|13|14|15) (barred|allowed)'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='rach emergency call allowed (0|1)'>
|
||||
<description>
|
||||
Using this command, you can determine if this cell permits the
|
||||
use of the 'EMERGENCY CALL' feature.
|
||||
|
||||
<warning>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.</warning>
|
||||
</description>
|
||||
</command>
|
||||
<command id='channel-descrption bs-ag-blks-res <0-7>'>
|
||||
<description>
|
||||
Using this command, you can specify how many blocks of the
|
||||
downlink CCCH should be reserved for exclusive usage as AGCH.
|
||||
|
||||
<warning>Not all BTS models currently support non-default configuration
|
||||
of this parameter.</warning>
|
||||
</description>
|
||||
</command>
|
||||
<command id='oml e1 tei <0-63>'>
|
||||
<description>
|
||||
Set the LAPD TEI used for the OML connection of this BTS.
|
||||
Only applies to classic E1 based A-bis.
|
||||
</description>
|
||||
</command>
|
||||
</node>
|
||||
<node id='16'>
|
||||
<child_of nodeid='15' />
|
||||
<name>TRX Configuration</name>
|
||||
<description>This is the configuration of a TRX.</description>
|
||||
<command id='nominal power <0-100>'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
<command id='max_power_red <0-100>'>
|
||||
<description>
|
||||
Request the actual RF transmit power of the BTS to be reduced
|
||||
by the specified number of dB.
|
||||
</description>
|
||||
</command>
|
||||
<command id='rsl e1 tei <0-63>'>
|
||||
<description>
|
||||
Set the LAPD TEI used for the RSL connection of this TRX.
|
||||
Only applies to classic E1 based A-bis.
|
||||
</description>
|
||||
</command>
|
||||
<command id='rf_locked (0|1)'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
</node>
|
||||
<node id='17'>
|
||||
<child_of nodeid='16' />
|
||||
<name>TS Configuration</name>
|
||||
<description>This is the configuration of a TS.</description>
|
||||
<command id='training_sequence_code <0-7>'>
|
||||
<description>
|
||||
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!
|
||||
</description>
|
||||
</command>
|
||||
<command id='hopping enabled (0|1)'>
|
||||
<description>
|
||||
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.
|
||||
</description>
|
||||
</command>
|
||||
</node>
|
||||
<node id='22'>
|
||||
<child_of nodeid='3' />
|
||||
<name>OML Commands</name>
|
||||
<description>This node allows to manipulate the OML state of
|
||||
a connected BTS. It is meant for testing during development.</description>
|
||||
</node>
|
||||
<node id='26'>
|
||||
<child_of nodeid='3' />
|
||||
<name>OML2000 Commands</name>
|
||||
<description>This node allows to issue OML2000 commands for
|
||||
Ericsson BTS. It is meant for testing during development.</description>
|
||||
</node>
|
||||
</vtydoc>
|
|
@ -0,0 +1,27 @@
|
|||
[[abis]]
|
||||
== Abis/IP Interface
|
||||
|
||||
=== A-bis Operation & Maintenance Link
|
||||
|
||||
The GSM Operation & Maintenance Link (OML) is specified in 3GPP TS
|
||||
12.21 and is used between a GSM Base-Transceiver-Station (BTS) and a GSM
|
||||
Base-Station-Controller (BSC). The default TCP port for OML is __3002__.
|
||||
The connection will be opened from the BTS to the BSC.
|
||||
|
||||
Abis OML is only specified over E1 interfaces. The Abis/IP
|
||||
implementation of OsmoBTS and OsmoBSC extend and/or deviate from the TS
|
||||
12.21 specification in several ways. Please see the _OsmoBTS Abis
|
||||
Protocol Specification_ <<osmobts-abis-spec>> for more information.
|
||||
|
||||
=== A-bis Radio Signalling Link
|
||||
|
||||
The GSM Radio Signalling Link (RSL) is specified in 3GPP TS 08.58 and is
|
||||
used between a GSM Base-Transceiver-Station and a GSM
|
||||
Base-Station-Controller (BSC). The default TCP port for RSL is __3003__.
|
||||
The connection will be opened from the BTS to BSC after it has been
|
||||
instructed by the BSC.
|
||||
|
||||
Abis RSL is only specified over E1 interfaces. The Abis/IP
|
||||
implementation of OsmoBTS and OsmoBSC extend and/or deviate from the TS
|
||||
08.58 specification in several ways. Please see the _OsmoBTS Abis
|
||||
Protocol Specification_ <<osmobts-abis-spec>> for more information.
|
|
@ -0,0 +1,75 @@
|
|||
|
||||
[[bibliography]]
|
||||
== Appendix A. Bibliography / References
|
||||
|
||||
[bibliography]
|
||||
- [[[osmobts-abis-spec]]] Neels Hofmeyer & Harald Welte. OsmoBTS Abis
|
||||
Protocol Specification. sysmocom.
|
||||
- [[[userman-osmobts]]] Osmocom Project: OsmoBTS User Manual.
|
||||
- [[[vty-ref-osmobts]]] Osmocom Project: OsmoBTS VTY Reference Manual.
|
||||
- [[[userman-osmobsc]]] Osmocom Project: OsmoBSC User Manual.
|
||||
- [[[vty-ref-osmobsc]]] Osmocom Project: OsmoBSC VTY Reference Manual.
|
||||
- [[[userman-osmopcu]]] Osmocom Project: OsmoPCU User Manual.
|
||||
- [[[vty-ref-osmopcu]]] Osmocom Project: OsmoPCU VTY Reference Manual.
|
||||
- [[[userman-osmonitb]]] Osmocom Project: OsmoNITB User Manual.
|
||||
- [[[vty-ref-osmonitb]]] Osmocom Project: OsmoNITB VTY Reference Manual.
|
||||
- [[[userman-osmosgsn]]] Osmocom Project: OsmoSGSN User Manual.
|
||||
- [[[vty-ref-osmosgsn]]] Osmocom Project: OsmoSGSN VTY Reference Manual.
|
||||
//- [[[userman-openggsn]]] Osmocom Project: OpenGGSN User Manual.
|
||||
|
||||
- [[[3gpp-ts-24-007]]] 3GPP TS 24.007: Mobile radio interface signalling
|
||||
layer 3; General Aspects
|
||||
http://www.3gpp.org/DynaReport/24007.htm
|
||||
- [[[3gpp-ts-24-008]]] 3GPP TS 24.008: Mobile radio interface Layer 3
|
||||
specification; Core network protocols; Stage 3.
|
||||
http://www.3gpp.org/dynareport/24008.htm
|
||||
- [[[3gpp-ts-44-006]]] 3GPP TS 44.006: Mobile Station - Base Station
|
||||
System (MS - BSS) interface; Data Link (DL) layer specification
|
||||
http://www.3gpp.org/DynaReport/44006.htm
|
||||
- [[[3gpp-ts-44-064]]] 3GPP TS 44.064: Mobile Station - Serving GPRS
|
||||
Support Node (MS-SGSN); Logical Link Control (LLC) Layer Specification
|
||||
http://www.3gpp.org/DynaReport/44064.htm
|
||||
- [[[3gpp-ts-48-008]]] 3GPP TS 48.008: Mobile Switching Centre - Base
|
||||
Station system (MSC-BSS) interface; Layer 3 specification
|
||||
http://www.3gpp.org/DynaReport/48008.htm
|
||||
- [[[3gpp-ts-48-016]]] 3GPP TS 48.016: General Packet Radio Service
|
||||
(GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN)
|
||||
interface; Network service
|
||||
http://www.3gpp.org/DynaReport/48016.htm
|
||||
- [[[3gpp-ts-48-018]]] 3GPP TS 48.018: General Packet Radio Service
|
||||
(GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN);
|
||||
BSS GPRS protocol (BSSGP)
|
||||
http://www.3gpp.org/DynaReport/48018.htm
|
||||
- [[[3gpp-ts-48-056]]] 3GPP TS 48.056: Base Station Controller - Base
|
||||
Transceiver Station (BSC - BTS) interface; Layer 2 specification
|
||||
http://www.3gpp.org/DynaReport/48056.htm
|
||||
- [[[3gpp-ts-48-058]]] 3GPP TS 48.058: Base Station Controller - Base
|
||||
Transceiver Station (BSC - BTS) Interface; Layer 3 specification
|
||||
http://www.3gpp.org/DynaReport/48058.htm
|
||||
- [[[3gpp-ts-52-021]]] 3GPP TS 52.021: Network Management (NM)
|
||||
procedures and messages on the A-bis interface
|
||||
http://www.3gpp.org/DynaReport/52021.htm
|
||||
|
||||
- [[[ietf-rfc791]]] IETF RFC 768: Internet Protocol
|
||||
https://tools.ietf.org/html/rfc791
|
||||
- [[[ietf-rfc793]]] IETF RFC 793: Transmission Control Protocol
|
||||
https://tools.ietf.org/html/rfc793
|
||||
- [[[ietf-rfc1350]]] IETF RFC 1350: Trivial File Transfer Protool
|
||||
https://tools.ietf.org/html/rfc1350
|
||||
- [[[ietf-rfc2131]]] IETF RFC 2131: Dynamic Host Configuration Protocol
|
||||
https://tools.ietf.org/html/rfc2131
|
||||
- [[[ietf-rfc3550]]] IETF RFC 3550: RTP: A Transport protocol for Real-Time Applications
|
||||
https://tools.ietf.org/html/rfc3550
|
||||
- [[[ietf-rfc4250]]] IETF RFC 4251: The Secure Shell (SSH) Protocol Architecture
|
||||
https://tools.ietf.org/html/rfc4251
|
||||
|
||||
- [[[itu-t-q921]]] ITU-T Q.921: ISDN user-network interface -
|
||||
Data link layer specification
|
||||
https://www.itu.int/rec/T-REC-Q.921/en
|
||||
|
||||
- [[[smpp-34]]] SMPP Develoepers Forum. Short Message Peer-to-Peer
|
||||
Protocol Specification v3.4
|
||||
http://docs.nimta.com/SMPP_v3_4_Issue1_2.pdf
|
||||
|
||||
- [[[gnu-agplv3]]] Free Software Foundation. GNU Affero General Public
|
||||
License. http://www.gnu.org/licenses/agpl-3.0.en.html
|
|
@ -0,0 +1,120 @@
|
|||
== BSC level configuration
|
||||
|
||||
The BSC component is shared between OsmoBSC and OsmoNITB. This chapter
|
||||
describes some of the configuration options related to this shared BSC
|
||||
component.
|
||||
|
||||
=== Hand-over
|
||||
|
||||
==== Hand-over in GSM
|
||||
|
||||
Hand-over is the process of changing a MS with a currently active
|
||||
dedicated channel from one BTS to another BTS. As opposed to idle mode,
|
||||
where the MS autonomously performs cell re-selection, in dedicated mode
|
||||
this happens under network control.
|
||||
|
||||
In order to determine when to perform hand-over, and to which cells, the
|
||||
network requests the MS to perform measurements on a list of neighbor
|
||||
cell channels, which the MS then reports back to the network in the form
|
||||
of GSM RR 'Measurement Result' messages. Those messages contain the
|
||||
downlink measurements as determined by the MS.
|
||||
|
||||
Furthermore, the BTS also performs measurements on the uplink, and
|
||||
communicates those by means of RSL to the BSC.
|
||||
|
||||
The hand-over decision is made by an algorithm that processes those
|
||||
measurement results and determines when to perform the hand-over.
|
||||
|
||||
==== Configuration of hand-over in OsmoBSC/OsmoNITB
|
||||
|
||||
OsmoBSC (like the internal BSC component of OsmoNITB) only support
|
||||
so-called intra-BSC hand-over, where the hand-over is performed between
|
||||
two BTSs within the same BSC.
|
||||
|
||||
Hand-over is enabled and configured by the use of a set of `handover`
|
||||
commands. Using those, you can tune the key parameters of the hand-over
|
||||
algorithm and adapt it to your specific environment.
|
||||
|
||||
.Example handover configuration snippet
|
||||
----
|
||||
handover 1 <1>
|
||||
handover window rxlev averaging 10 <2>
|
||||
handover window rxqual averaging 1 <3>
|
||||
handover window rxlev neighbor averaging 10 <4>
|
||||
handover power budget interval 6 <5>
|
||||
handover power budget hysteresis 3 <6>
|
||||
handover maximum distance 9999 <7>
|
||||
----
|
||||
<1> Enable hand-over
|
||||
<2> Set the RxLev averaging window for the serving cell to 10 measurements
|
||||
<3> Set the RxQual averaging window for the serving cell to 1
|
||||
measurement (no window)
|
||||
<4> Set the RxLev averaging for neighbor cells to 10 measurements
|
||||
<5> Check for the conditions of a power budget hand-over every 6 SACCH
|
||||
frames
|
||||
<6> A neighbor cell must be at least 3 dB stronger than the serving cell
|
||||
to be considered a candidate for hand-over
|
||||
<7> Perform a maximum distance hand-over if TA is larger 9999 (i.e. never)
|
||||
|
||||
//TODO: Move all to BSC node
|
||||
|
||||
=== Timer Configuration
|
||||
|
||||
The GSM specification specifies a variety of timers both on the network
|
||||
as well as on the mobile station side.
|
||||
|
||||
Those timers can be configured using the `timer tXXXX` command.
|
||||
|
||||
.Configurable Timers
|
||||
|===
|
||||
|node|timer|default|description
|
||||
|network|t3101|10|Timeout for 'Immediate Assignment' (sec)
|
||||
|network|t3103|?|Timeout for Handover (sec)
|
||||
|network|t3105|40|Repetition of 'Physical Information' (sec)
|
||||
|network|t3107|?|?
|
||||
|network|t3109|?|RSL SACCH deactivation timeout (sec)
|
||||
|network|t3111|?|RSL timeout to wait before releasing the RF channel (sec)
|
||||
|network|t3113|60|Time to try paging for a subscriber (sec)
|
||||
|network|t3115|?|?
|
||||
|network|t3117|?|?
|
||||
|network|t3119|?|?
|
||||
|network|t3122|10|Waiting time after 'Immediate Assignment Reject'
|
||||
|network|t3141|?|?
|
||||
|===
|
||||
|
||||
//TODO: split between BSC and MSC timers
|
||||
|
||||
=== Discontinuous Transmission (DTX)
|
||||
|
||||
GSM provides a full-duplex voice call service. However, in any
|
||||
civilized communication between human beings, only one of the
|
||||
participants is speaking at any given point in time. This means that
|
||||
most of the time, one of the two directions of the radio link is
|
||||
transmitting so-called 'silence frames'.
|
||||
|
||||
During such periods of quiescence in one of the two directions, it is
|
||||
possible to suppress transmission of most of the radio bursts, as there
|
||||
is no voice signal to transport. GSM calls this feature 'Discontinuous
|
||||
Transmission'. It exists separately for uplink (DTXu) and downlink
|
||||
(DTXd).
|
||||
|
||||
Downlink DTX is only permitted on non-primary transceivers (!= TRX0), as
|
||||
TRX0 must always transmit at constant output power to ensure it is
|
||||
detected during cell selection.
|
||||
|
||||
Uplink DTX is possible on any TRX, and serves primarily two uses:
|
||||
|
||||
possible on any TRX, and serves primarily two uses:
|
||||
|
||||
. reducing the MS battery consumption by transmitting at a lower duty cycle
|
||||
. reducing the uplink interference caused in surrounding cells that
|
||||
re-use the same ARFCN.
|
||||
|
||||
DTS for both uplink and downlink is implemented in the BTS. Not all BTS
|
||||
models support it.
|
||||
|
||||
The Osmocom BSC component can instruct the BTS to enable or disable
|
||||
uplink and/or downlink DTX by means of A-bis OML.
|
||||
|
||||
//TODO: Test/implement, at least for uplink
|
||||
//TODO: Move to BSC
|
|
@ -0,0 +1,269 @@
|
|||
[[bts]]
|
||||
== Reviewing and Provisioning BTS configuration
|
||||
|
||||
The main functionality of the BSC component is to manage BTSs. As such,
|
||||
provisioning BTSs within the BSC is one of the most common tasks during
|
||||
BSC operation. Just like about anything else in OpenBSC, they are
|
||||
configured using the VTY.
|
||||
|
||||
BTSs are internally numbered with integer numbers starting from "0" for
|
||||
the first BTS. BTS numbers have to be contiguous, so you cannot
|
||||
configure 0,1,2 and then 5.
|
||||
|
||||
|
||||
=== Reviewing current BTS status and configuration
|
||||
|
||||
In order to view the status and properties of a BTS, you can issue the
|
||||
`show bts` command. If used without any BTS number, it will display
|
||||
information about all provisioned BTS numbers.
|
||||
|
||||
----
|
||||
OpenBSC> show bts 0
|
||||
BTS 0 is of nanobts type in band DCS1800, has CI 0 LAC 1, BSIC 63, TSC 7 and 1 TRX
|
||||
Description: (null)
|
||||
MS Max power: 15 dBm
|
||||
Minimum Rx Level for Access: -110 dBm
|
||||
Cell Reselection Hysteresis: 4 dBm
|
||||
RACH TX-Integer: 9
|
||||
RACH Max transmissions: 7
|
||||
System Information present: 0x0000007e, static: 0x00000000
|
||||
Unit ID: 200/0/0, OML Stream ID 0xff
|
||||
NM State: Oper 'Enabled', Admin 2, Avail 'OK'
|
||||
Site Mgr NM State: Oper 'Enabled', Admin 0, Avail 'OK'
|
||||
Paging: 0 pending requests, 0 free slots
|
||||
OML Link state: connected.
|
||||
Current Channel Load:
|
||||
TCH/F: 0% (0/5)
|
||||
SDCCH8: 0% (0/8)
|
||||
----
|
||||
|
||||
You can also review the status of the TRXs configured within the BTSs of
|
||||
this BSC by using `show trx`:
|
||||
|
||||
----
|
||||
OpenBSC> show trx 0 0
|
||||
TRX 0 of BTS 0 is on ARFCN 871
|
||||
Description: (null)
|
||||
RF Nominal Power: 23 dBm, reduced by 0 dB, resulting BS power: 23 dBm
|
||||
NM State: Oper 'Enabled', Admin 2, Avail 'OK'
|
||||
Baseband Transceiver NM State: Oper 'Enabled', Admin 2, Avail 'OK'
|
||||
ip.access stream ID: 0x00
|
||||
----
|
||||
|
||||
The output can be restricted to the TRXs of one specified BTS number
|
||||
(`show trx 0`) or even that of a single specified TRX within a
|
||||
specified BTS (`show trx 0 0`).
|
||||
|
||||
Furthermore, information on the individual timeslots can be shown by
|
||||
means of `show timeslot`. The output can be restricted to the
|
||||
timeslots of a single BTS (`show timeslot 0`) or that of a single
|
||||
TRX (`show timeslot 0 0`). Finally, you can restrict the output to
|
||||
a single timeslot by specifying the BTS, TRX and TS numbers (`show
|
||||
timeslot 0 0 4`).
|
||||
|
||||
----
|
||||
OpenBSC> show timeslot 0 0 0
|
||||
BTS 0, TRX 0, Timeslot 0, phys cfg CCCH, TSC 7
|
||||
NM State: Oper 'Enabled', Admin 2, Avail 'OK'
|
||||
OpenBSC> show timeslot 0 0 1
|
||||
BTS 0, TRX 0, Timeslot 1, phys cfg SDCCH8, TSC 7
|
||||
NM State: Oper 'Enabled', Admin 2, Avail 'OK'
|
||||
----
|
||||
|
||||
|
||||
=== Provisioning a new BTS
|
||||
|
||||
In order to provision BTSs, you have to enter the BTS config node of the
|
||||
VTY. In order to configure BTS 0, you can issue the following sequence
|
||||
of commands:
|
||||
----
|
||||
OpenBSC> enable
|
||||
OpenBSC# configure terminal
|
||||
OpenBSC(config)# network
|
||||
OpenBSC(config-net)# bts 0
|
||||
OpenBSC(config-net-bts)#
|
||||
----
|
||||
|
||||
At this point, you have a plethora of commands, in fact an entire
|
||||
hierarchy of commands to configure all aspects of the BTS, as well as
|
||||
each of its TRX and each timeslot within each TRX. For a full
|
||||
reference, please consult the respective chapter in the VTY reference of
|
||||
OpenBSC.
|
||||
|
||||
BTS configuration depends quite a bit on the specific BTS vendor and
|
||||
model. The section below provides just one possible example for the
|
||||
case of a sysmoBTS.
|
||||
|
||||
|
||||
----
|
||||
OpenBSC(config-net-bts)# type sysmobts
|
||||
OpenBSC(config-net-bts)# band DCS1800
|
||||
OpenBSC(config-net-bts)# description The new BTS in Baikonur
|
||||
OpenBSC(config-net-bts)# location_area_code 2342
|
||||
OpenBSC(config-net-bts)# cell_identity 5
|
||||
OpenBSC(config-net-bts)# base_station_id_code 63
|
||||
OpenBSC(config-net-bts)# ip.access unit_id 8888 0
|
||||
OpenBSC(config-net-bts)# ms max power 40
|
||||
OpenBSC(config-net-bts)# trx 0
|
||||
OpenBSC(config-net-bts-trx)# arfcn 871
|
||||
OpenBSC(config-net-bts-trx)# nominal power 23
|
||||
OpenBSC(config-net-bts-trx)# max_power_red 0
|
||||
OpenBSC(config-net-bts-trx)# timeslot 0
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config CCCH+SDCCH4
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
OpenBSC(config-net-bts-trx)# timeslot 1
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
OpenBSC(config-net-bts-trx)# timeslot 2
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
OpenBSC(config-net-bts-trx)# timeslot 3
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
OpenBSC(config-net-bts-trx)# timeslot 4
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
OpenBSC(config-net-bts-trx)# timeslot 5
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
OpenBSC(config-net-bts-trx)# timeslot 6
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
OpenBSC(config-net-bts-trx)# timeslot 7
|
||||
OpenBSC(config-net-bts-trx-ts)# phys_chan_config PDCH
|
||||
OpenBSC(config-net-bts-trx-ts)# exit
|
||||
----
|
||||
|
||||
|
||||
=== System Information configuration
|
||||
|
||||
A GSM BTS periodically transmits a series of 'SYSTEM INFORMATION'
|
||||
messages to mobile stations, both via the BCCH in idle mode, was well as
|
||||
via the SACCH in dedicated mode. There are many different types of such
|
||||
messages. For their detailed contents and encoding, please see _3GPP TS
|
||||
24.008_ <<3gpp-ts-24-008>>.
|
||||
|
||||
For each of the 'SYSTEM INFORMATION' message types, you can configure to
|
||||
have the BSC generate it automatically ('computed'), or you can specify
|
||||
the respective binary message as a string of hexadecimal digits.
|
||||
|
||||
The default configuration is to compute all (required) 'SYSTEM
|
||||
INFORMATION' messages automatically.
|
||||
|
||||
Please see the _OsmoBSC VTY Reference Manual_ <<vty-ref-osmobsc>> for
|
||||
further information, particularly on the following commands:
|
||||
|
||||
* `system-information (1|2|3|4|5|6|7|8|9|10|13|16|17|18|19|20|2bis|2ter|2quater|5bis|5ter) mode (static|computed)`
|
||||
* `system-information (1|2|3|4|5|6|7|8|9|10|13|16|17|18|19|20|2bis|2ter|2quater|5bis|5ter) static HEXSTRING`
|
||||
|
||||
|
||||
=== Neighbor List configuration
|
||||
|
||||
Every BTS sends a list of ARFCNs of neighbor cells
|
||||
. within its 'SYSTEM INFORMATION 2' (and 2bis/2ter) messages on the BCCH
|
||||
. within its 'SYSTEM INFORMATION 5' messages on SACCH in dedicated mode
|
||||
|
||||
For every BTS config node in the VTY, you can specify the behavior of
|
||||
the neighbor list using the `neighbor list mode` VTY command:
|
||||
|
||||
automatic::
|
||||
Automatically generate a list of neighbor cells using all other
|
||||
BTSs configured in the VTY
|
||||
manual::
|
||||
Manually specify the neighbor list by means of `neighbor-list
|
||||
(add|del) arfcn <0-1023>` commands, having identical neighbor lists on
|
||||
BCCH (SI2) and SACCH (SI5)
|
||||
|
||||
manual-si5::
|
||||
Manually specify the neighbor list by means of `neighbor-list
|
||||
(add|del) arfcn <0-1023>` for BCCH (SI2) and a separate neighbor list by
|
||||
means of `si5 neighbor-list (add|del) arfcn <0-1023>` for SACCH (SI5).
|
||||
|
||||
|
||||
=== Configuring GPRS PCU parameters of a BTS
|
||||
|
||||
In the case of BTS models using Abis/IP (IPA), the GPRS PCU is located
|
||||
inside the BTS. The BTS then establishes a Gb connection to the SGSN.
|
||||
|
||||
All the BTS-internal PCU configuration is performed via A-bis OML by
|
||||
means of configuring the 'CELL', 'NSVC' (NS Virtual Connection and 'NSE'
|
||||
(NS Entity).
|
||||
|
||||
There is one 'CELL' node and one 'NSE' node, but there are two 'NSVC'
|
||||
nodes. At the time of this writing, only the NSVC 0 is supported by
|
||||
OsmoBTS, while both NSVC are supported by the ip.access nanoBTS.
|
||||
|
||||
The respective VTY configuration parameters are described below. They
|
||||
all exist beneath each BTS VTY config node.
|
||||
|
||||
But let's first start with a small example
|
||||
|
||||
.Example configuration of GPRS PCU parameters at VTY BTS node
|
||||
----
|
||||
OpenBSC(config-net-bts)# gprs mode gprs
|
||||
OpenBSC(config-net-bts)# gprs routing area 1
|
||||
OpenBSC(config-net-bts)# gprs cell bvci 1234
|
||||
OpenBSC(config-net-bts)# gprs nsei 1234
|
||||
OpenBSC(config-net-bts)# gprs nsvc 0 nsvci 1234
|
||||
OpenBSC(config-net-bts)# gprs nsvc 0 local udp port 23000
|
||||
OpenBSC(config-net-bts)# gprs nsvc 0 remote udp port 23000
|
||||
OpenBSC(config-net-bts)# gprs nsvc 0 remote ip 192.168.100.239
|
||||
----
|
||||
|
||||
|
||||
=== More explanation about the PCU config parameters
|
||||
|
||||
//FIXME: should this go into VTY additions?
|
||||
|
||||
==== `gprs mode (none|gprs|egprs)`
|
||||
|
||||
This command determines if GPRS (or EGPRS) services are to be enabled in
|
||||
this cell at all.
|
||||
|
||||
|
||||
==== `gprs cell bvci <2-65535>`
|
||||
|
||||
Configures the 'BSSGP Virtual Circuit Identifier'. It must be unique
|
||||
between all BGSGP connections to one SGSN.
|
||||
|
||||
NOTE: It is up to the system administrator to ensure all PCUs are
|
||||
allocated an unique bvci. OsmoBSC will not ensure this policy.
|
||||
|
||||
|
||||
==== `gprs nsei <0-65535>`
|
||||
|
||||
Configures the 'NS Entity Identifier'. It must be unique between all NS
|
||||
connections to one SGSN.
|
||||
|
||||
NOTE: It is up to the system administrator to ensure all PCUs are
|
||||
allocated an unique bvci. OsmoBSC will not ensure this policy.
|
||||
|
||||
|
||||
==== `gprs nsvc <0-1> nsvci <0-65535>`
|
||||
|
||||
Configures the 'NS Virtual Connection Identifier'. It must be unique
|
||||
between all NS virtual connections to one SGSN.
|
||||
|
||||
NOTE: It is up to the system administrator to ensure all PCUs are
|
||||
allocated an unique nsvci. OsmoBSC will not ensure this policy.
|
||||
|
||||
|
||||
==== `gprs nsvc <0-1> local udp port <0-65535>`
|
||||
|
||||
Configures the local (PCU side) UDP port for the NS-over-UDP link.
|
||||
|
||||
|
||||
==== `gprs nsvc <0-1> remote udp port <0-65535>`
|
||||
|
||||
Configures the remote (SGSN side) UDP port for the NS-over-UDP link.
|
||||
|
||||
|
||||
==== `gprs nsvc <0-1> remote ip A.B.C.D`
|
||||
|
||||
Configures the remote (SGSN side) UDP port for the NS-over-UDP link.
|
||||
|
||||
|
||||
==== `gprs ns timer (tns-block|tns-block-retries|tns-reset|tns-reset-retries|tns-test|tns-alive|tns-alive-retries)` <0-255>
|
||||
|
||||
Configures the various GPRS NS related timers. Please check the GPRS NS
|
||||
specification for the detailed meaning of those timers.
|
|
@ -0,0 +1,175 @@
|
|||
[[common-control-if]]
|
||||
== Osmocom Control Interface
|
||||
|
||||
The VTY interface as described in <<vty>> is aimed at human interaction
|
||||
with the respective Osmocom program.
|
||||
|
||||
Other programs *should not* use the VTY interface to interact with the
|
||||
Osmocom software, as parsing the textual representation is cumbersome,
|
||||
inefficient, and will break every time the formatting is changed by the
|
||||
Osmocom developers.
|
||||
|
||||
Instead, the 'Control Interface' was introduced as a programmatic
|
||||
interface that can be used to interact with the respective program.
|
||||
|
||||
=== Control Interface Protocol
|
||||
|
||||
The control interface protocol is a mixture of binary framing with text
|
||||
based payload.
|
||||
|
||||
The protocol for the control interface is wrapped inside the IPA
|
||||
multiplex header with the stream identifier set to IPAC_PROTO_OSMO (0xEE).
|
||||
|
||||
.IPA header for control protocol
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 24
|
||||
node_height = 24
|
||||
|
||||
0-15: Length (network byte order)
|
||||
16-23: Stream ID (0xEE)
|
||||
}
|
||||
----
|
||||
|
||||
Inside the IPA header is a single byte of extension header with protocol
|
||||
ID 0x00 which indicates the control interface.
|
||||
|
||||
.IPA extension header for control protocol
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 8
|
||||
node_height = 24
|
||||
|
||||
0-7: Protocol (0x00)
|
||||
}
|
||||
----
|
||||
|
||||
After the concatenation of the two above headers, the plain-text payload
|
||||
message starts. The format of that plain text is illustrated for each
|
||||
operation in the respective message sequence chart in the chapters
|
||||
below.
|
||||
|
||||
The fields specified below follow the following meaning:
|
||||
|
||||
<id>::
|
||||
A numeric identifier, uniquely identifying this particular
|
||||
operation. `0` is not allowed. It will be echoed back in any
|
||||
response to a particular request.
|
||||
<var>::
|
||||
The name of the variable / field affected by the GET / SET /
|
||||
TRAP operation. Which variables/fields are available is
|
||||
dependent on the specific application under control.
|
||||
<val>::
|
||||
The value of the variable / field
|
||||
<reason>::
|
||||
A text formatted, human-readable reason why the operation
|
||||
resulted in an error.
|
||||
|
||||
==== GET operation
|
||||
|
||||
The GET operation is performed by an external application to get a
|
||||
certain value from inside the Osmocom application.
|
||||
|
||||
.Control Interface GET operation (successful outcome)
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], ctrl [label="Control Interface"];
|
||||
|
||||
cli => ctrl [label="GET <id> <var>"];
|
||||
cli <= ctrl [label="GET_REPLY <id> <var> <val>"];
|
||||
}
|
||||
----
|
||||
|
||||
.Control Interface GET operation (unsuccessful outcome)
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], ctrl [label="Control Interface"];
|
||||
|
||||
cli => ctrl [label="GET <id> <var>"];
|
||||
cli <= ctrl [label="ERROR <id> <reason>"];
|
||||
}
|
||||
----
|
||||
|
||||
==== SET operation
|
||||
|
||||
The SET operation is performed by an external application to set a value
|
||||
inside the Osmocom application.
|
||||
|
||||
.Control Interface SET operation (successful outcome)
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], ctrl [label="Control Interface"];
|
||||
|
||||
cli => ctrl [label="SET <id> <var> <val>"];
|
||||
cli <= ctrl [label="SET_REPLY <id> <var> <val>"];
|
||||
}
|
||||
----
|
||||
|
||||
.Control Interface SET operation (unsuccessful outcome)
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], ctrl [label="Control Interface"];
|
||||
|
||||
cli => ctrl [label="SET <id> <var> <val>"];
|
||||
cli <= ctrl [label="ERROR <id> <reason>"];
|
||||
}
|
||||
----
|
||||
|
||||
==== TRAP operation
|
||||
|
||||
The program can at any time issue a trap. The term is used in the
|
||||
spirit of SNMP.
|
||||
|
||||
.Control Interface TRAP operation
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], ctrl [label="Control Interface"];
|
||||
|
||||
cli <= ctrl [label="TRAP <var> <val>"];
|
||||
}
|
||||
----
|
||||
|
||||
=== Control Interface python example: `bsc_control.py`
|
||||
|
||||
In the `openbsc.git` repository, there is an example python script
|
||||
called `openbsc/contrib/bsc_control.py` which implements the Osmocom
|
||||
control interface protocol.
|
||||
|
||||
You can use this tool either stand-alone to perform control interface
|
||||
operations against an Osmocom program, or you can use it as a reference
|
||||
for developing your own python software talking to the control
|
||||
interface.
|
||||
|
||||
==== Setting a value
|
||||
|
||||
.Example: Use `bsc_control.py` to set the short network name of OsmoNITB
|
||||
----
|
||||
$ ./bsc_control.py -d localhost -s short-name 32C3
|
||||
Got message: SET_REPLY 1 short-name 32C3
|
||||
----
|
||||
|
||||
==== Getting a value
|
||||
|
||||
.Example: Use `bsc_control.py` to get the mnc of OsmoNITB
|
||||
----
|
||||
$ ./bsc_control.py -d localhost -g mnc
|
||||
Got message: GET_REPLY 1 mnc 262
|
||||
----
|
||||
|
||||
==== Listening for traps
|
||||
|
||||
You can use `bsc_control.py` to listen for traps the following way:
|
||||
|
||||
.Example: Using `bsc_control.py` to listen for traps:
|
||||
----
|
||||
$ ./bsc_control.py -d localhost -m
|
||||
<1>
|
||||
----
|
||||
<1> the command will not return and wait for any TRAP messages to arrive
|
|
@ -0,0 +1,109 @@
|
|||
== Gb interface using libosmogb
|
||||
|
||||
'libosmogb' is part of the libosmocore.git repository and implements the
|
||||
Gb interface protocol stack consisting of the NS and BSSGP layers. It
|
||||
is used in a variety of Osmocom project, including OsmoSGSN,
|
||||
OsmoGbProxy and OsmoPCU.
|
||||
|
||||
This section describes the configuration that libosmogb exposes via the
|
||||
VTY.
|
||||
|
||||
=== Gb interface configuration
|
||||
|
||||
==== NS-over-UDP configuration
|
||||
|
||||
The GPRS-NS protocol can be encapsulated in UDP/IP. This is the default
|
||||
encapsulation for IP based GPRS systems.
|
||||
|
||||
.Example: GPRS NS-over-UDP configuration
|
||||
----
|
||||
OsmoSGSN(config-ns)# encapsulation udp local-ip 127.0.0.1 <1>
|
||||
OsmoSGSN(config-ns)# encapsulation udp local-port 23000 <2>
|
||||
----
|
||||
<1> Set the local side IP address for NS-over-UDP
|
||||
<2> Set the local side UDP port number for NS-over-UDP. 23000 is the default
|
||||
|
||||
==== NS-over-FR-GRE configuration
|
||||
|
||||
The GPRS-NS protocol can alternatively be encapsulated over Frame Relay
|
||||
(FR). Traditionally this is communicated over SDH/PDH media, which we
|
||||
don't support. However, we can encapsulate the FR in GRE, and then that
|
||||
in IP.
|
||||
|
||||
The resulting NS-FR-GRE-IP stack can be converted by an off-the-shelf
|
||||
router with FR and IP support.
|
||||
|
||||
.Example: GPRS NS-over-FR-GRE configuration
|
||||
----
|
||||
OsmoSGSN(config-ns)# encapsulation framerelay-gre enabled 1 <1>
|
||||
OsmoSGSN(config-ns)# encapsulation framerelay-gre local-ip 127.0.0.1 <2>
|
||||
----
|
||||
<1> Enable FR-GRE encapsulation
|
||||
<2> Set the local side IP address for NS-over-FR-GRE
|
||||
|
||||
==== NS Timer configuration
|
||||
|
||||
The NS protocol features a number of configurable timers.
|
||||
|
||||
.List of configurable NS timers
|
||||
|===
|
||||
|tns-block|(un)blocking timer timeout (secs)
|
||||
|tns-block-retries|(un)blocking timer; number of retries
|
||||
|tns-reset|reset timer timeout (secs)
|
||||
|tns-reset-retries|reset timer; number of retries
|
||||
|tns-test|test timer timeout (secs)
|
||||
|tns-alive|alive timer timeout(secs)
|
||||
|tns-alive-retries|alive timer; number of retries
|
||||
|===
|
||||
|
||||
=== Examining Gb interface status
|
||||
|
||||
There are several commans that can help to inspect and analyze the
|
||||
currently running system status with respect to the Gb interfaces.
|
||||
|
||||
.Example: Inspecting NS state
|
||||
----
|
||||
OsmoSGSN> show ns
|
||||
Encapsulation NS-UDP-IP Local IP: 127.0.0.1, UDP Port: 23000
|
||||
Encapsulation NS-FR-GRE-IP Local IP: 0.0.0.0
|
||||
----
|
||||
FIXME
|
||||
|
||||
FIXME: show ns stats
|
||||
|
||||
.Example: Inspecting BSSGP state
|
||||
----
|
||||
----
|
||||
FIXME
|
||||
|
||||
FIXME: show nse
|
||||
|
||||
=== FIXME
|
||||
|
||||
==== Blocking / Unblocking / Resetting NS Virtual Connections
|
||||
|
||||
The user can manually perform operations on individual NSVCs:
|
||||
|
||||
* blocking a NSVC
|
||||
* unblocking a NSVC
|
||||
* resetting a NSVC
|
||||
|
||||
The VTY command used for this is the `nsvc (nsei|nsvci) <0-65535>
|
||||
(block|unblock|reset)` command available from the ENABLE node.
|
||||
|
||||
|
||||
=== Gb interface logging filters
|
||||
|
||||
There are some Gb-interface specific filters for the libosmocore
|
||||
logging subsystem, which can help to reduce the logged output to
|
||||
messages pertaining to a certain NS or BSSGP connection only.
|
||||
|
||||
.Example: enabling a log filter for a given NSEI
|
||||
----
|
||||
OsmoSGSN> logging filter nsvc nsei 23
|
||||
----
|
||||
|
||||
.Example: enabling a log filter for a given NSVCI
|
||||
----
|
||||
OsmoSGSN> logging filter nsvc nsvci 23
|
||||
----
|
|
@ -0,0 +1,482 @@
|
|||
[[licenses-gfdl]]
|
||||
== Appendix A. GNU Free Documentation License
|
||||
|
||||
Version 1.3, 3 November 2008
|
||||
|
||||
Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. <http://fsf.org/>
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
[[licenses-gfdl-section-1]]
|
||||
=== PREAMBLE
|
||||
|
||||
The purpose of this License is to make a manual, textbook, or other
|
||||
functional and useful document ``free'' in the sense of freedom: to
|
||||
assure everyone the effective freedom to copy and redistribute it,
|
||||
with or without modifying it, either commercially or noncommercially.
|
||||
Secondarily, this License preserves for the author and publisher a way
|
||||
to get credit for their work, while not being considered responsible
|
||||
for modifications made by others.
|
||||
|
||||
This License is a kind of ``copyleft'', which means that derivative
|
||||
works of the document must themselves be free in the same sense. It
|
||||
complements the GNU General Public License, which is a copyleft
|
||||
license designed for free software.
|
||||
|
||||
We have designed this License in order to use it for manuals for free
|
||||
software, because free software needs free documentation: a free
|
||||
program should come with manuals providing the same freedoms that the
|
||||
software does. But this License is not limited to software manuals;
|
||||
it can be used for any textual work, regardless of subject matter or
|
||||
whether it is published as a printed book. We recommend this License
|
||||
principally for works whose purpose is instruction or reference.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-2]]
|
||||
=== APPLICABILITY AND DEFINITIONS
|
||||
|
||||
This License applies to any manual or other work, in any medium, that
|
||||
contains a notice placed by the copyright holder saying it can be
|
||||
distributed under the terms of this License. Such a notice grants a
|
||||
world-wide, royalty-free license, unlimited in duration, to use that
|
||||
work under the conditions stated herein. The ``Document'', below,
|
||||
refers to any such manual or work. Any member of the public is a
|
||||
licensee, and is addressed as ``you''. You accept the license if you
|
||||
copy, modify or distribute the work in a way requiring permission
|
||||
under copyright law.
|
||||
|
||||
anchor:modified-version[Modified Version]
|
||||
|
||||
A ``Modified Version'' of the Document means any work containing the
|
||||
Document or a portion of it, either copied verbatim, or with
|
||||
modifications and/or translated into another language.
|
||||
|
||||
anchor:secondary-section[Secondary Section]
|
||||
|
||||
A ``Secondary Section'' is a named appendix or a front-matter section of
|
||||
the Document that deals exclusively with the relationship of the
|
||||
publishers or authors of the Document to the Document's overall
|
||||
subject (or to related matters) and contains nothing that could fall
|
||||
directly within that overall subject. (Thus, if the Document is in
|
||||
part a textbook of mathematics, a <<secondary-section>> may not explain
|
||||
any mathematics.) The relationship could be a matter of historical
|
||||
connection with the subject or with related matters, or of legal,
|
||||
commercial, philosophical, ethical or political position regarding
|
||||
them.
|
||||
|
||||
anchor:invariant-sections[Invariant Sections]
|
||||
|
||||
The ``Invariant Sections'' are certain <<secondary-section>> whose titles
|
||||
are designated, as being those of <<invariant-sections>>, in the notice
|
||||
that says that the Document is released under this License. If a
|
||||
section does not fit the above definition of Secondary then it is not
|
||||
allowed to be designated as Invariant. The Document may contain zero
|
||||
<<invariant-sections>>. If the Document does not identify any Invariant
|
||||
Sections then there are none.
|
||||
|
||||
anchor:cover-texts[Cover Texts]
|
||||
|
||||
The ``Cover Texts'' are certain short passages of text that are listed,
|
||||
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
|
||||
the Document is released under this License. A Front-Cover Text may
|
||||
be at most 5 words, and a Back-Cover Text may be at most 25 words.
|
||||
|
||||
anchor:transparent[Transparent]
|
||||
|
||||
A ``Transparent'' copy of the Document means a machine-readable copy,
|
||||
represented in a format whose specification is available to the
|
||||
general public, that is suitable for revising the document
|
||||
straightforwardly with generic text editors or (for images composed of
|
||||
pixels) generic paint programs or (for drawings) some widely available
|
||||
drawing editor, and that is suitable for input to text formatters or
|
||||
for automatic translation to a variety of formats suitable for input
|
||||
to text formatters. A copy made in an otherwise <<transparent>> file
|
||||
format whose markup, or absence of markup, has been arranged to thwart
|
||||
or discourage subsequent modification by readers is not <<transparent>>.
|
||||
An image format is not <<transparent>> if used for any substantial amount
|
||||
of text. A copy that is not <<transparent>> is called ``Opaque''.
|
||||
|
||||
Examples of suitable formats for <<transparent>> copies include plain
|
||||
ASCII without markup, Texinfo input format, LaTeX input format, SGML
|
||||
or XML using a publicly available DTD, and standard-conforming simple
|
||||
HTML, PostScript or PDF designed for human modification. Examples of
|
||||
transparent image formats include PNG, XCF and JPG. Opaque formats
|
||||
include proprietary formats that can be read and edited only by
|
||||
proprietary word processors, SGML or XML for which the DTD and/or
|
||||
processing tools are not generally available, and the
|
||||
machine-generated HTML, PostScript or PDF produced by some word
|
||||
processors for output purposes only.
|
||||
|
||||
anchor:title-page[Title Page]
|
||||
|
||||
The ``Title Page'' means, for a printed book, the title page itself,
|
||||
plus such following pages as are needed to hold, legibly, the material
|
||||
this License requires to appear in the title page. For works in
|
||||
formats which do not have any title page as such, <<title-page>> means
|
||||
the text near the most prominent appearance of the work's title,
|
||||
preceding the beginning of the body of the text.
|
||||
|
||||
The ``publisher'' means any person or entity that distributes copies of
|
||||
the Document to the public.
|
||||
|
||||
A section ``Entitled XYZ'' means a named subunit of the Document whose
|
||||
title either is precisely XYZ or contains XYZ in parentheses following
|
||||
text that translates XYZ in another language. (Here XYZ stands for a
|
||||
specific section name mentioned below, such as ``Acknowledgements'',
|
||||
``Dedications'', ``Endorsements'', or ``History''.) To ``Preserve the Title''
|
||||
of such a section when you modify the Document means that it remains a
|
||||
section ``Entitled XYZ'' according to this definition.
|
||||
|
||||
The Document may include Warranty Disclaimers next to the notice which
|
||||
states that this License applies to the Document. These Warranty
|
||||
Disclaimers are considered to be included by reference in this
|
||||
License, but only as regards disclaiming warranties: any other
|
||||
implication that these Warranty Disclaimers may have is void and has
|
||||
no effect on the meaning of this License.
|
||||
|
||||
[[licenses-gfdl-section-3]]
|
||||
=== VERBATIM COPYING
|
||||
|
||||
You may copy and distribute the Document in any medium, either
|
||||
commercially or noncommercially, provided that this License, the
|
||||
copyright notices, and the license notice saying this License applies
|
||||
to the Document are reproduced in all copies, and that you add no
|
||||
other conditions whatsoever to those of this License. You may not use
|
||||
technical measures to obstruct or control the reading or further
|
||||
copying of the copies you make or distribute. However, you may accept
|
||||
compensation in exchange for copies. If you distribute a large enough
|
||||
number of copies you must also follow the conditions in section
|
||||
<<licenses-gfdl-section-4>>.
|
||||
|
||||
You may also lend copies, under the same conditions stated above, and
|
||||
you may publicly display copies.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-4]]
|
||||
=== COPYING IN QUANTITY
|
||||
|
||||
If you publish printed copies (or copies in media that commonly have
|
||||
printed covers) of the Document, numbering more than 100, and the
|
||||
Document's license notice requires <<cover-texts>>, you must enclose the
|
||||
copies in covers that carry, clearly and legibly, all these Cover
|
||||
Texts: Front-<<cover-texts>> on the front cover, and
|
||||
Back-<<cover-texts>> on
|
||||
the back cover. Both covers must also clearly and legibly identify
|
||||
you as the publisher of these copies. The front cover must present
|
||||
the full title with all words of the title equally prominent and
|
||||
visible. You may add other material on the covers in addition.
|
||||
Copying with changes limited to the covers, as long as they preserve
|
||||
the title of the Document and satisfy these conditions, can be treated
|
||||
as verbatim copying in other respects.
|
||||
|
||||
If the required texts for either cover are too voluminous to fit
|
||||
legibly, you should put the first ones listed (as many as fit
|
||||
reasonably) on the actual cover, and continue the rest onto adjacent
|
||||
pages.
|
||||
|
||||
If you publish or distribute Opaque copies of the Document numbering
|
||||
more than 100, you must either include a machine-readable <<transparent>>
|
||||
copy along with each Opaque copy, or state in or with each Opaque copy
|
||||
a computer-network location from which the general network-using
|
||||
public has access to download using public-standard network protocols
|
||||
a complete <<transparent>> copy of the Document, free of added material.
|
||||
If you use the latter option, you must take reasonably prudent steps,
|
||||
when you begin distribution of Opaque copies in quantity, to ensure
|
||||
that this <<transparent>> copy will remain thus accessible at the stated
|
||||
location until at least one year after the last time you distribute an
|
||||
Opaque copy (directly or through your agents or retailers) of that
|
||||
edition to the public.
|
||||
|
||||
It is requested, but not required, that you contact the authors of the
|
||||
Document well before redistributing any large number of copies, to
|
||||
give them a chance to provide you with an updated version of the
|
||||
Document.
|
||||
|
||||
[[licenses-gfdl-section-5]]
|
||||
=== MODIFICATIONS
|
||||
|
||||
You may copy and distribute a <<modified-version>> of the Document under
|
||||
the conditions of sections 2 and 3 above, provided that you release
|
||||
the <<modified-version>> under precisely this License, with the <<modified-version>>
|
||||
filling the role of the Document, thus licensing distribution
|
||||
and modification of the <<modified-version>> to whoever possesses a copy
|
||||
of it. In addition, you must do these things in the <<modified-version>>:
|
||||
|
||||
a. Use in the <<title-page>> (and on the covers, if any) a title distinct
|
||||
from that of the Document, and from those of previous versions
|
||||
(which should, if there were any, be listed in the History section
|
||||
of the Document). You may use the same title as a previous version
|
||||
if the original publisher of that version gives permission.
|
||||
b. List on the <<title-page>>, as authors, one or more persons or entities
|
||||
responsible for authorship of the modifications in the <<modified-version>>,
|
||||
together with at least five of the principal authors of the
|
||||
Document (all of its principal authors, if it has fewer than five),
|
||||
unless they release you from this requirement.
|
||||
c. State on the <<title-page>> the name of the publisher of the
|
||||
<<modified-version>>, as the publisher.
|
||||
d. Preserve all the copyright notices of the Document.
|
||||
e. Add an appropriate copyright notice for your modifications
|
||||
adjacent to the other copyright notices.
|
||||
f. Include, immediately after the copyright notices, a license notice
|
||||
giving the public permission to use the <<modified-version>> under the
|
||||
terms of this License, in the form shown in the Addendum below.
|
||||
g. Preserve in that license notice the full lists of <<invariant-sections>>
|
||||
and required <<cover-texts>> given in the Document's license notice.
|
||||
h. Include an unaltered copy of this License.
|
||||
i. Preserve the section Entitled ``History'', Preserve its Title, and add
|
||||
to it an item stating at least the title, year, new authors, and
|
||||
publisher of the <<modified-version>> as given on the <<title-page>>. If
|
||||
there is no section Entitled ``History'' in the Document, create one
|
||||
stating the title, year, authors, and publisher of the Document as
|
||||
given on its <<title-page>>, then add an item describing the <<modified-version>>
|
||||
as stated in the previous sentence.
|
||||
j. Preserve the network location, if any, given in the Document for
|
||||
public access to a <<transparent>> copy of the Document, and likewise
|
||||
the network locations given in the Document for previous versions
|
||||
it was based on. These may be placed in the ``History'' section.
|
||||
You may omit a network location for a work that was published at
|
||||
least four years before the Document itself, or if the original
|
||||
publisher of the version it refers to gives permission.
|
||||
k. For any section Entitled ``Acknowledgements'' or ``Dedications'',
|
||||
Preserve the Title of the section, and preserve in the section all
|
||||
the substance and tone of each of the contributor acknowledgements
|
||||
and/or dedications given therein.
|
||||
l. Preserve all the <<invariant-sections>> of the Document,
|
||||
unaltered in their text and in their titles. Section numbers
|
||||
or the equivalent are not considered part of the section titles.
|
||||
m. Delete any section Entitled ``Endorsements''. Such a section
|
||||
may not be included in the <<modified-vesion>>.
|
||||
n. Do not retitle any existing section to be Entitled ``Endorsements''
|
||||
or to conflict in title with any <<invariant-sections>>.
|
||||
o. Preserve any Warranty Disclaimers.
|
||||
|
||||
If the <<modified-version>> includes new front-matter sections or
|
||||
appendices that qualify as <<secondary-section>> and contain no material
|
||||
copied from the Document, you may at your option designate some or all
|
||||
of these sections as invariant. To do this, add their titles to the
|
||||
list of <<invariant-sections>> in the <<modified-version>>'s license notice.
|
||||
These titles must be distinct from any other section titles.
|
||||
|
||||
You may add a section Entitled ``Endorsements'', provided it contains
|
||||
nothing but endorsements of your <<modified-version>> by various
|
||||
parties--for example, statements of peer review or that the text has
|
||||
been approved by an organization as the authoritative definition of a
|
||||
standard.
|
||||
|
||||
You may add a passage of up to five words as a Front-Cover Text, and a
|
||||
passage of up to 25 words as a Back-Cover Text, to the end of the list
|
||||
of <<cover-texts>> in the <<modified-version>>. Only one passage of
|
||||
Front-Cover Text and one of Back-Cover Text may be added by (or
|
||||
through arrangements made by) any one entity. If the Document already
|
||||
includes a cover text for the same cover, previously added by you or
|
||||
by arrangement made by the same entity you are acting on behalf of,
|
||||
you may not add another; but you may replace the old one, on explicit
|
||||
permission from the previous publisher that added the old one.
|
||||
|
||||
The author(s) and publisher(s) of the Document do not by this License
|
||||
give permission to use their names for publicity for or to assert or
|
||||
imply endorsement of any <<modified-version>>.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-6]]
|
||||
=== COMBINING DOCUMENTS
|
||||
|
||||
You may combine the Document with other documents released under this
|
||||
License, under the terms defined in section 4 above for modified
|
||||
versions, provided that you include in the combination all of the
|
||||
<<invariant-sections>> of all of the original documents, unmodified, and
|
||||
list them all as <<invariant-sections>> of your combined work in its
|
||||
license notice, and that you preserve all their Warranty Disclaimers.
|
||||
|
||||
The combined work need only contain one copy of this License, and
|
||||
multiple identical <<invariant-sections>> may be replaced with a single
|
||||
copy. If there are multiple <<invariant-sections>> with the same name but
|
||||
different contents, make the title of each such section unique by
|
||||
adding at the end of it, in parentheses, the name of the original
|
||||
author or publisher of that section if known, or else a unique number.
|
||||
Make the same adjustment to the section titles in the list of
|
||||
<<invariant-sections>> in the license notice of the combined work.
|
||||
|
||||
In the combination, you must combine any sections Entitled ``History''
|
||||
in the various original documents, forming one section Entitled
|
||||
``History''; likewise combine any sections Entitled ``Acknowledgements'',
|
||||
and any sections Entitled ``Dedications''. You must delete all sections
|
||||
Entitled ``Endorsements''.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-7]]
|
||||
=== COLLECTIONS OF DOCUMENTS
|
||||
|
||||
You may make a collection consisting of the Document and other
|
||||
documents released under this License, and replace the individual
|
||||
copies of this License in the various documents with a single copy
|
||||
that is included in the collection, provided that you follow the rules
|
||||
of this License for verbatim copying of each of the documents in all
|
||||
other respects.
|
||||
|
||||
You may extract a single document from such a collection, and
|
||||
distribute it individually under this License, provided you insert a
|
||||
copy of this License into the extracted document, and follow this
|
||||
License in all other respects regarding verbatim copying of that
|
||||
document.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-8]]
|
||||
=== AGGREGATION WITH INDEPENDENT WORKS
|
||||
|
||||
A compilation of the Document or its derivatives with other separate
|
||||
and independent documents or works, in or on a volume of a storage or
|
||||
distribution medium, is called an ``aggregate'' if the copyright
|
||||
resulting from the compilation is not used to limit the legal rights
|
||||
of the compilation's users beyond what the individual works permit.
|
||||
When the Document is included in an aggregate, this License does not
|
||||
apply to the other works in the aggregate which are not themselves
|
||||
derivative works of the Document.
|
||||
|
||||
If the Cover Text requirement of section 3 is applicable to these
|
||||
copies of the Document, then if the Document is less than one half of
|
||||
the entire aggregate, the Document's <<cover-texts>> may be placed on
|
||||
covers that bracket the Document within the aggregate, or the
|
||||
electronic equivalent of covers if the Document is in electronic form.
|
||||
Otherwise they must appear on printed covers that bracket the whole
|
||||
aggregate.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-9]]
|
||||
=== TRANSLATION
|
||||
|
||||
Translation is considered a kind of modification, so you may
|
||||
distribute translations of the Document under the terms of section 4.
|
||||
Replacing <<invariant-sections>> with translations requires special
|
||||
permission from their copyright holders, but you may include
|
||||
translations of some or all <<invariant-sections>> in addition to the
|
||||
original versions of these <<invariant-sections>>. You may include a
|
||||
translation of this License, and all the license notices in the
|
||||
Document, and any Warranty Disclaimers, provided that you also include
|
||||
the original English version of this License and the original versions
|
||||
of those notices and disclaimers. In case of a disagreement between
|
||||
the translation and the original version of this License or a notice
|
||||
or disclaimer, the original version will prevail.
|
||||
|
||||
If a section in the Document is Entitled ``Acknowledgements'',
|
||||
``Dedications'', or ``History'', the requirement (section 4) to Preserve
|
||||
its Title (section 1) will typically require changing the actual
|
||||
title.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-10]]
|
||||
=== TERMINATION
|
||||
|
||||
You may not copy, modify, sublicense, or distribute the Document
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense, or distribute it is void, and
|
||||
will automatically terminate your rights under this License.
|
||||
|
||||
However, if you cease all violation of this License, then your license
|
||||
from a particular copyright holder is reinstated (a) provisionally,
|
||||
unless and until the copyright holder explicitly and finally
|
||||
terminates your license, and (b) permanently, if the copyright holder
|
||||
fails to notify you of the violation by some reasonable means prior to
|
||||
60 days after the cessation.
|
||||
|
||||
Moreover, your license from a particular copyright holder is
|
||||
reinstated permanently if the copyright holder notifies you of the
|
||||
violation by some reasonable means, this is the first time you have
|
||||
received notice of violation of this License (for any work) from that
|
||||
copyright holder, and you cure the violation prior to 30 days after
|
||||
your receipt of the notice.
|
||||
|
||||
Termination of your rights under this section does not terminate the
|
||||
licenses of parties who have received copies or rights from you under
|
||||
this License. If your rights have been terminated and not permanently
|
||||
reinstated, receipt of a copy of some or all of the same material does
|
||||
not give you any rights to use it.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-11]]
|
||||
=== FUTURE REVISIONS OF THIS LICENSE
|
||||
|
||||
The Free Software Foundation may publish new, revised versions of the
|
||||
GNU Free Documentation License from time to time. Such new versions
|
||||
will be similar in spirit to the present version, but may differ in
|
||||
detail to address new problems or concerns. See
|
||||
http://www.gnu.org/copyleft/.
|
||||
|
||||
Each version of the License is given a distinguishing version number.
|
||||
If the Document specifies that a particular numbered version of this
|
||||
License ``or any later version'' applies to it, you have the option of
|
||||
following the terms and conditions either of that specified version or
|
||||
of any later version that has been published (not as a draft) by the
|
||||
Free Software Foundation. If the Document does not specify a version
|
||||
number of this License, you may choose any version ever published (not
|
||||
as a draft) by the Free Software Foundation. If the Document
|
||||
specifies that a proxy can decide which future versions of this
|
||||
License can be used, that proxy's public statement of acceptance of a
|
||||
version permanently authorizes you to choose that version for the
|
||||
Document.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-12]]
|
||||
=== RELICENSING
|
||||
|
||||
``Massive Multiauthor Collaboration Site'' (or ``MMC Site'') means any
|
||||
World Wide Web server that publishes copyrightable works and also
|
||||
provides prominent facilities for anybody to edit those works. A
|
||||
public wiki that anybody can edit is an example of such a server. A
|
||||
``Massive Multiauthor Collaboration'' (or ``MMC'') contained in the site
|
||||
means any set of copyrightable works thus published on the MMC site.
|
||||
|
||||
``CC-BY-SA'' means the Creative Commons Attribution-Share Alike 3.0
|
||||
license published by Creative Commons Corporation, a not-for-profit
|
||||
corporation with a principal place of business in San Francisco,
|
||||
California, as well as future copyleft versions of that license
|
||||
published by that same organization.
|
||||
|
||||
``Incorporate'' means to publish or republish a Document, in whole or in
|
||||
part, as part of another Document.
|
||||
|
||||
An MMC is ``eligible for relicensing'' if it is licensed under this
|
||||
License, and if all works that were first published under this License
|
||||
somewhere other than this MMC, and subsequently incorporated in whole or
|
||||
in part into the MMC, (1) had no cover texts or invariant sections, and
|
||||
(2) were thus incorporated prior to November 1, 2008.
|
||||
|
||||
The operator of an MMC Site may republish an MMC contained in the site
|
||||
under CC-BY-SA on the same site at any time before August 1, 2009,
|
||||
provided the MMC is eligible for relicensing.
|
||||
|
||||
|
||||
[[licenses-gfdl-section-13]]
|
||||
=== ADDENDUM: How to use this License for your documents
|
||||
|
||||
To use this License in a document you have written, include a copy of
|
||||
the License in the document and put the following copyright and
|
||||
license notices just after the title page:
|
||||
|
||||
----
|
||||
Copyright (c) YEAR YOUR NAME.
|
||||
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 no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
|
||||
A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.
|
||||
----
|
||||
|
||||
If you have <<invariant-sections>>, Front-<<cover-texts>> and Back-<<cover-texts>>,
|
||||
replace the ``with...Texts.'' line with this:
|
||||
|
||||
----
|
||||
with the Invariant Sections being LIST THEIR TITLES, with the
|
||||
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
|
||||
----
|
||||
|
||||
If you have <<invariant-sections>> without <<cover-texts>>, or some other
|
||||
combination of the three, merge those two alternatives to suit the
|
||||
situation.
|
||||
|
||||
If your document contains nontrivial examples of program code, we
|
||||
recommend releasing these examples in parallel under your choice of
|
||||
free software license, such as the GNU General Public License,
|
||||
to permit their use in free software.
|
|
@ -0,0 +1,278 @@
|
|||
[glossary]
|
||||
== Glossary
|
||||
|
||||
3GPP::
|
||||
3rd Generation Partnership Project
|
||||
A Interface::
|
||||
Interface between BTS and BSC, traditionally over E1 (_3GPP TS 48.008_
|
||||
<<3gpp-ts-48-008>>)
|
||||
A3/A8::
|
||||
Algorithm 3 and 8; Authentication and key generation algorithm in GSM
|
||||
and GPRS. COMP128v1/v2/v3 or MILENAGE are typically used
|
||||
A5::
|
||||
Algorithm 5; Air-interface encryption of GSM; currently only A5/0
|
||||
through A5/3 are in use
|
||||
Abis Interface::
|
||||
Interface between BTS and BSC, traditionally over E1 (_3GPP TS 48.058_
|
||||
<<3gpp-ts-48-058>> and _3GPP TS 52.021_ <<3gpp-ts-52-021>>)
|
||||
AGCH::
|
||||
Access Grant Channel on Um interface; used to assign a dedicated
|
||||
channel in response to RACH request
|
||||
AGPL::
|
||||
GNU Affero General Public License, a copyleft-style Freee Software License
|
||||
ARFCN::
|
||||
Absolute Radio Frequency Channel Number, specifying a tuple of uplink
|
||||
and downlink frequency
|
||||
AUC::
|
||||
Authentication Center; central database of authentication key material
|
||||
for each subscriber
|
||||
BCCH::
|
||||
Broadcast Control Channel on Um interface; used to broadcast
|
||||
information about Cell and its neighbors
|
||||
BCC::
|
||||
Base Station Color Code; short identifier of BTS, lower part of BSIC
|
||||
BTS::
|
||||
Base Transceiver Station
|
||||
BSC::
|
||||
Base Station Controller
|
||||
BSIC::
|
||||
Base Station Identity Code; 16bit identifier of BTS within location area
|
||||
BSSGP::
|
||||
Base Station Subsystem Gateway Protocol (_3GPP TS 48.018_ <<3gpp-ts-48-018>>)
|
||||
BVCI::
|
||||
BSSGP Virtual Circuit Identifier
|
||||
CBCH::
|
||||
Cell Broadcast Channel; used to transmit Cell Broadcast SMS (SMS-CB)
|
||||
CC::
|
||||
Call Control; Part of the GSM Layer 3 Protocol
|
||||
CCCH::
|
||||
Common Control Channel on Um interface; consists of RACH (uplink),
|
||||
BCCH, PCH, AGCH (all downlink)
|
||||
Cell::
|
||||
A cell in a cellular network, served by a BTS
|
||||
CEPT::
|
||||
Conférence européenne des administrations des postes et des
|
||||
télécommunications; European onference of Postal and Telecommunications
|
||||
Administrations.
|
||||
CGI::
|
||||
Cell Global Identifier comprised of MCC, MNC, LAC and BSIC
|
||||
dB::
|
||||
deci-Bel; relative logarithmic unit
|
||||
dBm::
|
||||
deci-Bel (milliwatt); unit of measurement for signal strength of radio
|
||||
signals
|
||||
DHCP::
|
||||
Dynamic Host Configuration Protocol (_IETF RFC 2131_ <<ietf-rfc2131>>
|
||||
downlink::
|
||||
Direction of messages / signals from the network core towards the
|
||||
mobile phone
|
||||
DSP::
|
||||
Digital Signal Processor
|
||||
dvnixload::
|
||||
Tool to program UBL and the Bootloader on a sysmoBTS
|
||||
EDGE::
|
||||
Enhanced Data rates for GPRS Evolution; Higher-speed improvement of
|
||||
GPRS; introduces 8PSK
|
||||
EGPRS::
|
||||
Enhanced GPRS; the part of EDGE relating to GPRS services
|
||||
ESME::
|
||||
External SMS Entity. An external application interfacing with a SMSC
|
||||
over SMPP
|
||||
ETSI::
|
||||
European Telecommunications Standardization Institute
|
||||
FPGA::
|
||||
Field Programmable Gate Array. Programmable digital logic
|
||||
Gb::
|
||||
Interface between PCU and SGSN in GPRS/EDGE network; uses NS, BSSGP, LLC
|
||||
GERAN::
|
||||
GPRS/EDGE Radio Access Network
|
||||
GFDL::
|
||||
GNU Free Documentation License, a copyleft-style Documentation License
|
||||
GGSN::
|
||||
GPRS Gateway Support Node; gateway between GPRS and external (IP) network
|
||||
GMSK::
|
||||
Gaussian Minimum Shift Keying; modulation used for GSM and GPRS
|
||||
GPL::
|
||||
GNU General Public License, a copyleft-style Freee Software License
|
||||
Gp::
|
||||
Gp interface between SGSN and GGSN; usees GTP protocol
|
||||
GPS::
|
||||
Global Positioning System. Provides a high accuracy clock reference
|
||||
next to position.
|
||||
GSM::
|
||||
Global System for Mobile Communications. ETSI/3GPP Standard of a 2G
|
||||
digital cellular network
|
||||
GSMTAP::
|
||||
GSM tap. Pseudo-Standard for encapsulating GSM protocol layers over
|
||||
UDP/IP for means of analysis
|
||||
GTP::
|
||||
GPRS Tunnel Protocol; used between SGSN and GGSN
|
||||
HLR::
|
||||
Home Location Register; central subscriber database of a GSM network
|
||||
HPLMN::
|
||||
Home PLMN; the network that has issued the subscriber SIM and has his record in HLR
|
||||
IE::
|
||||
Information Element
|
||||
IMEI::
|
||||
International Mobile Equipment Identity; unique identifier for the mobile phone
|
||||
IMSI::
|
||||
International Mobile Subscriber Identity; 15-digit unique identifier
|
||||
for the subscriber/SIM, starts with MCC/MNC of issuing operator
|
||||
IP::
|
||||
Internet Protocol (_IETF RFC 791_ <<ietf-rfc791>>)
|
||||
IPA::
|
||||
The _ip.access GSM over IP_ protocol, used to multiplex a single TCP connection
|
||||
LAC::
|
||||
Location Area Code; 16bit identifier of Location Area within network
|
||||
LAPD::
|
||||
Link Access Protocol, D-Channel (_ITU-T Q.921_ <<itu-t-q921>>)
|
||||
LAPDm::
|
||||
Link Access Protocol Mobile (_3GPP TS 44.006_ <<3gpp-ts-44-006>>)
|
||||
LLC::
|
||||
Logical Link Control; GPRS protocol between MS and SGSN (_3GPP TS
|
||||
44.064_ <<3gpp-ts-44-064>>)
|
||||
Location Area::
|
||||
Location Area; a geographic area containing multiple BTS
|
||||
MCC::
|
||||
Mobile Country Code; unique identifier of a country, e.g. 262 for Germany
|
||||
MGW::
|
||||
Media Gateway
|
||||
MM::
|
||||
Mobility Management; Part of the GSM Layer 3 Protocol
|
||||
MNC::
|
||||
Mobile Network Code; identifies network within a country; assigned by national regulator
|
||||
MNO::
|
||||
Mobile Network Operator; Operator with real physical radio network under his MCC/MNC
|
||||
MS::
|
||||
Mobile Station, the mobile phone / GSM Modem
|
||||
MSC::
|
||||
Mobile Switching Center
|
||||
MSISDN::
|
||||
Mobile Subscriber ISDN Number; telephone number of the subscriber
|
||||
MVNO::
|
||||
Mobile Virtual Network Operator; Operator without physical radio network
|
||||
NCC::
|
||||
Network Color Code; assigned by national regulator
|
||||
NITB::
|
||||
Network In The Box; integrating BSC,MSC,VLR,HLR,SMSC functions
|
||||
NSEI::
|
||||
NS Entity Identifier
|
||||
NVCI::
|
||||
NS Virtual Circuit Identifier
|
||||
NWL::
|
||||
Network Listen; ability of some BTS to receive downlink from other BTSs
|
||||
NS::
|
||||
Network Service; protocol on Gb interface (_3GPP TS 48.016_ <<3gpp-ts-48-016>>)
|
||||
OCXO::
|
||||
Oven Controlled Crystal Oscillator. A very high-precision oscillator.
|
||||
OML::
|
||||
Operation & Maintenance Link (ETSI/_3GPP TS 52.021_ <<3gpp-ts-52-021>>)
|
||||
OpenBSC::
|
||||
Open Source implementation of GSM network elements, specifically OsmoBSC, OsmoNITB, OsmoSGSN
|
||||
OpenGGSN::
|
||||
Open Source implementation of a GPRS Packet Control Unit
|
||||
OpenVPN::
|
||||
Open-Source Virtual Private Network. Used to establish encrypted private networks over untrusted public networks.
|
||||
Osmocom::
|
||||
Open Source MObile COMmunications; Collaborative community for
|
||||
implementing communications protocols and systems, including GSM, GPRS,
|
||||
TETRA, DECT, GMR and others
|
||||
OsmoBSC::
|
||||
Open Source implementation of a GSM Base Station Controller
|
||||
OsmoNITB::
|
||||
Open Source implementation of a GSM Network In The Box, comprising
|
||||
functionality that traditionally required BSC, MSC, VLR, HLR, AUC, SMSC
|
||||
OsmoSGSN::
|
||||
Open Source implementation of a Serving GPRS Support Node
|
||||
OsmoPCU::
|
||||
Open Source implementation of a GPRS Packet Control Unit
|
||||
PCH::
|
||||
Paging Channel on downlink Um interface; used by network to page a MS
|
||||
PCU::
|
||||
Packet Control Unit; used to manage Layer 2 of the GPRS radio interface
|
||||
PDCH::
|
||||
Packet Data Channel on Um interface; used for GPRS/EDGE signalling + user data
|
||||
PLMN::
|
||||
Public Land Mobile Network; specification language for a single GSM network
|
||||
RAC::
|
||||
Routing Area Code; 16bit identifier for a Routing Area within a Location Area
|
||||
RACH::
|
||||
Random Access Channel on uplink Um interface; used by MS to request
|
||||
establishment of a dedicated channel
|
||||
RF::
|
||||
Radio Frequency (synonymous to transceiver equipment, e.g. being on or off)
|
||||
Roaming::
|
||||
Procedure in which a subscriber of one network is using the radio
|
||||
network of another network, often in different countries, but national
|
||||
roaming exists in some countries, too
|
||||
Routing Area::
|
||||
Routing Area; GPRS specific sub-division of Location Area
|
||||
RR::
|
||||
Radio Resources; Part of the GSM Layer 3 Protocol
|
||||
RSL::
|
||||
Radio Signalling Link (_3GPP TS 48.058_ <<3gpp-ts-48-058>>)
|
||||
RTP::
|
||||
Real-Time Transport Protocol (_IETF RFC 3550_ <<ietf-rfc3550>>). Used to
|
||||
transport audio/video streams over UDP/IP
|
||||
SACCH::
|
||||
Slow Associate Control Channel on Um interface; bundled to a TCH or
|
||||
SDCCH, used for signalling in parallel to active dedicated channel
|
||||
SDCCH::
|
||||
Slow Dedicated Control Channel on Um interface; used for signalling
|
||||
and SMS transport in GSM
|
||||
SDK::
|
||||
Software Development Kit
|
||||
SIM::
|
||||
Subscriber Identity Module; small chip card storing subscriber identity
|
||||
Site::
|
||||
A site is a location where one or multiple BTSs are installed,
|
||||
typically three BTS for three sectors
|
||||
SMPP::
|
||||
Short Message Peer-to-Peer; TCP based protocol how external entities
|
||||
can interface with SMSC
|
||||
SMSC::
|
||||
Short Message Service Center; Store-and-forward relay for short messages
|
||||
SSH::
|
||||
Secure Shell, _IETF RFC 4250_ <<ietf-rfc4251>> to 4254
|
||||
syslog::
|
||||
System logging service of UNIX-like operating systems
|
||||
System Information::
|
||||
A set of downlink messages on the BCCH and SACCH of the Um interface
|
||||
describing properties of the cell and network
|
||||
TCH::
|
||||
Traffic Channel, used for circuit-switched user traffic (mostly voice)
|
||||
in GSM
|
||||
TCP::
|
||||
Transmission Control Protocol (_IETF RFC 793_ <<ietf-rfc793>>)
|
||||
TFTP::
|
||||
Trivial File Transfer Protocol (_IETF RFC 1350_ <<ietf-rfc1350>>)
|
||||
TRX::
|
||||
Transceiver; Element of a BTS serving a single carrier
|
||||
u-Boot::
|
||||
The name of a boot loader used in a lot of embedded systems
|
||||
UBI::
|
||||
A MTD wear leveling system to deal with NAND flash in Linux
|
||||
UBL::
|
||||
The name for the initial bootloader loaded by the TI Davinci SoC
|
||||
UDP::
|
||||
User Datagram Protocol (_IETF RFC 768_ <<ietf-rfc768>>)
|
||||
UICC::
|
||||
Universal Integrated Chip Circuit. A smart card according to FIXME
|
||||
Um interface::
|
||||
U mobile; Radio interface between MS and BTS
|
||||
uplink::
|
||||
Direction of messages / signals from the mobile phone towards the network
|
||||
USIM::
|
||||
Universal Subscriber Identity Module; Application running on an UICC
|
||||
to provide subscriber identity for UMTS and GSM networks.
|
||||
VCTCXO::
|
||||
Voltage Controlled, Temperature Compensated Crystal Oscillator. A
|
||||
precision oscillator, better than a classic Crystal Oscillator, but
|
||||
inferior to an OCXO.
|
||||
VPLMN::
|
||||
Visited PLMN; the network in which the subscriber is currently
|
||||
registered. May differ from HPLMN when on roaming.
|
||||
VTY::
|
||||
Virtual TeletYpe. A textual command-line interface for configuration
|
||||
and introspection.
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
[[logging]]
|
||||
== libosmocore Logging System
|
||||
|
||||
|
||||
In any reasonably complex software it is important to understand how to
|
||||
enable and configure logging in order to get a better insight into what
|
||||
is happening, and to be able to follow the course of action. We
|
||||
therefore ask the reader to bear with us while we explain how the
|
||||
logging subsystem works and how it is configured.
|
||||
|
||||
Most Osmocom Software (like `osmo-bts`, `osmo-bsc`, `osmo-nitb`,
|
||||
`osmo-sgsn` and many others) uses the same common logging system.
|
||||
|
||||
This chapter describes the architecture and configuration of this common
|
||||
logging system.
|
||||
|
||||
The logging system is composed of
|
||||
|
||||
* log targets (where to log),
|
||||
* log categories (who is creating the log line),
|
||||
* log levels (controlling the verbosity of logging), and
|
||||
* log filters (filtering or suppressing certain messages).
|
||||
|
||||
All logging is done in human-readable ASCII-text. The logging system is
|
||||
configured by means of VTY commands that can either be entered
|
||||
interactively, or read from a configuration file at process start time.
|
||||
|
||||
=== Logging to the VTY
|
||||
|
||||
Logging messages to the interactive command-line interface (VTY) is most
|
||||
useful for occasional investigation by the system administrator.
|
||||
|
||||
Logging to the VTY is disabled by default, and needs to be enabled
|
||||
explicitly for each such session. This means that multiple concurrent
|
||||
VTY sessions each have their own logging configuration. Once you close
|
||||
a VTY session, the log target will be destroyed and your log settings be
|
||||
lost. If you re-connect to the VTY, you have to again activate and
|
||||
configure logging, if you wish.
|
||||
|
||||
To create a logging target bound to a VTY, you have to use the following
|
||||
command: `logging enable` This doesn't really activate the
|
||||
generation of any output messages yet, it merely creates and attaches a
|
||||
log target to the VTY session. The newly-created target still doesn't
|
||||
have any filter installed, i.e. __all log messages will be suppressed
|
||||
by default__
|
||||
|
||||
Next, you can configure the log levels for your VTY session. Each
|
||||
sub-system of the program in question typically logs its messages as a
|
||||
different category, allowing fine-grained control over which log
|
||||
messages you will or will not see. For example, in OpenBSC, there are
|
||||
categories for the protocol layers `rsl`, `rr`, `mm`,
|
||||
`cc` and many others. To get a a list of categories interactively
|
||||
on the vty, type: `logging level ?`
|
||||
|
||||
For each of those categories, you can set an independent log level,
|
||||
controlling the level of verbosity. Log levels include:
|
||||
|
||||
fatal::
|
||||
Fatal messages, causing abort and/or re-start of a process.
|
||||
This __shouldn't happen__.
|
||||
|
||||
error::
|
||||
An actual error has occurred, its cause should be further
|
||||
investigated by the administrator.
|
||||
|
||||
|
||||
notice::
|
||||
A noticeable event has occurred, which is not
|
||||
considered to be an error.
|
||||
|
||||
info::
|
||||
Some information about normal/regular system
|
||||
activity is provided.
|
||||
|
||||
debug::
|
||||
Verbose information about internal processing of the system,
|
||||
used for debugging purpose. This will log the most.
|
||||
|
||||
The log levels are inclusive, e.g. if you select __info__, then this
|
||||
really means that all events with a level of at least __info__ will be
|
||||
logged, i.e. including events of __notice__, __error__ and __fatal__.
|
||||
|
||||
So for example, in OpenBSC, to set the log level of the Mobility
|
||||
Management category to info, you can use the following command:
|
||||
`log level mm info`.
|
||||
|
||||
Equally, to set the log level of the Call Control category to debug, you
|
||||
can use:
|
||||
`log level cc debug`
|
||||
|
||||
Finally, after having configured the levels, you still need to set the
|
||||
filter. The default behavior is to filter out everything, i.e. not to
|
||||
log anything. The reason is quite simple: On a busy production setup,
|
||||
logging all events for a given subsystem may very quickly be flooding
|
||||
your console before you have a chance to set a more restrictive filter.
|
||||
|
||||
To request no filtering, i.e. see all messages, you may use:
|
||||
`log filter all 1`
|
||||
|
||||
As another example, to only see messages relating to a particular
|
||||
subscriber identified by his IMSI, you may use:
|
||||
`log filter imsi 262020123456789`
|
||||
|
||||
TIP: If many messages are being logged to a VTY session, it may be hard
|
||||
to impossible to still use the same session for any commands. We
|
||||
therefore recommend to open a second VTY session in parallel, and use
|
||||
one only for logging, while the other is used for interacting with the
|
||||
system.
|
||||
|
||||
=== Logging to a file
|
||||
|
||||
As opposed to Logging to the VTY, logging to files is persistent and
|
||||
stored in the configuration file. As such, it is configured in
|
||||
sub-nodes below the configuration node. There can be any number of log
|
||||
files active, each of them having different settings regarding levels /
|
||||
subsystems.
|
||||
|
||||
To configure a new log file, enter the following sequence of commands:
|
||||
----
|
||||
OpenBSC> enable
|
||||
OpenBSC# configure terminal
|
||||
OpenBSC(config)# log file /path/to/my/file
|
||||
OpenBSC(config-log)#
|
||||
----
|
||||
|
||||
This leaves you at the config-log prompt, from where you can set the
|
||||
detailed configuration for this log file. The available commands at
|
||||
this point are identical to configuring logging on the VTY, they include
|
||||
`logging filter`, `logging level` as well as `logging color`
|
||||
and `logging timestamp`.
|
||||
|
||||
TIP: Don't forget to use the `copy running-config startup-config` (or
|
||||
its short-hand `write file`) command to make your logging configuration
|
||||
persistent across application re-start.
|
||||
|
||||
NOTE: libosmocore currently does not provide file close-and-reopen
|
||||
support by SIGHUP, as used by popular log file rotating solutions.
|
||||
Please contact the Osmocom developers if you require this feature to be
|
||||
implemented.
|
||||
|
||||
|
||||
=== Logging to syslog
|
||||
|
||||
syslog is a standard for computer data logging maintained by the IETF.
|
||||
Unix-like operating systems like GNU/Linux provide several syslog
|
||||
compatible log daemons that receive log messages generated by
|
||||
application programs.
|
||||
|
||||
libosmocore based applications can log messages to syslog by using the
|
||||
syslog log target. You can configure syslog logging by issuing the
|
||||
following commands on the VTY:
|
||||
|
||||
----
|
||||
OpenBSC> enable
|
||||
OpenBSC# configure terminal
|
||||
OpenBSC(config)# log syslog daemon
|
||||
OpenBSC(config-log)#
|
||||
----
|
||||
|
||||
This leaves you at the config-log prompt, from where you can set the
|
||||
detailed configuration for this log file. The available commands at
|
||||
this point are identical to configuring logging on the VTY, they include
|
||||
`logging filter`, `logging level` as well as `logging color`
|
||||
and `logging timestamp`.
|
||||
|
||||
NOTE: Syslog daemons will normally automatically prefix every message
|
||||
with a time-stamp, so you should disable the libosmocore time-stamping
|
||||
by issuing the `logging timestamp 0` command.
|
||||
|
||||
|
||||
=== Logging to stderr
|
||||
|
||||
If you're not running the respective application as a daemon in the
|
||||
background, you can also use the stderr log target in order to log to
|
||||
the standard error file descriptor of the process.
|
||||
|
||||
In order to configure logging to stderr, you can use the following
|
||||
commands:
|
||||
----
|
||||
OpenBSC> enable
|
||||
OpenBSC# configure terminal
|
||||
OpenBSC(config)# log stderr
|
||||
OpenBSC(config-log)#
|
||||
----
|
|
@ -0,0 +1,258 @@
|
|||
== Osmocom Authentication Protocol (OAP)
|
||||
|
||||
The Osmocom Authentication Protocol employs mutual authentication to
|
||||
register a client with a server over an IPA connection. Milenage is used
|
||||
as the authentication algorithm, where client and server have a shared
|
||||
secret.
|
||||
|
||||
For example, an SGSN, as OAP client, may use its SGSN ID to register
|
||||
with a MAP proxy, an OAP server.
|
||||
|
||||
=== Connection
|
||||
|
||||
The protocol expects that a reliable, ordered, packet boundaries
|
||||
preserving connection is used (e.g. IPA over TCP).
|
||||
|
||||
=== Using IPA
|
||||
|
||||
By default, the following identifiers should be used:
|
||||
- IPA protocol: 0xee (OSMO)
|
||||
- IPA OSMO protocol extension: 0x06 (OAP)
|
||||
|
||||
=== Procedures
|
||||
|
||||
.Ideal communication sequence
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], srv [label="Server"];
|
||||
|
||||
cli => srv [label="Register (ID)"];
|
||||
cli <= srv [label="Challenge (RAND+AUTN)"];
|
||||
cli => srv [label="Challenge Result (XRES)"];
|
||||
cli <= srv [label="Register Result"];
|
||||
}
|
||||
----
|
||||
|
||||
.Variation "test setup"
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], srv [label="Server"];
|
||||
|
||||
cli => srv [label="Register (ID)"];
|
||||
cli <= srv [label="Register Result"];
|
||||
}
|
||||
----
|
||||
|
||||
.Variation "invalid sequence nr":
|
||||
[mscgen]
|
||||
----
|
||||
msc {
|
||||
cli [label="Client"], srv [label="Server"];
|
||||
|
||||
cli => srv [label="Register (ID)"];
|
||||
cli <= srv [label="Challenge (RAND+AUTN)"];
|
||||
cli => srv [label="Sync Request (AUTS)"];
|
||||
cli <= srv [label="Challenge (RAND+AUTN')"];
|
||||
cli => srv [label="Challenge Result (XRES)"];
|
||||
cli <= srv [label="Register Result"];
|
||||
}
|
||||
----
|
||||
|
||||
==== Register
|
||||
|
||||
The client sends a REGISTER_REQ message containing an identifier number.
|
||||
|
||||
[[oap-challenge]]
|
||||
==== Challenge
|
||||
|
||||
The OAP server (optionally) sends back a CHALLENGE_REQ, containing random bytes
|
||||
and a milenage authentication token generated from these random bytes, using a
|
||||
shared secret, to authenticate itself to the OAP client. The server may omit
|
||||
this challenge entirely, based on its configuration, and immediately reply with
|
||||
a Register Result response. If the client cannot be registered (e.g. id is
|
||||
invalid), the server sends a REGISTER_ERR response.
|
||||
|
||||
==== Challenge Result
|
||||
|
||||
When the client has received a Challenge, it may verify the server's
|
||||
authenticity and validity of the sequence number (included in AUTN), and, if
|
||||
valid, reply with a CHALLENGE_RES message. This shall contain an XRES
|
||||
authentication token generated by milenage from the same random bytes received
|
||||
from the server and the same shared secet. If the client decides to cancel the
|
||||
registration (e.g. invalid AUTN), it shall not reply to the CHALLENGE_REQ; a
|
||||
CHALLENGE_ERR message may be sent, but is not mandatory. For example, the
|
||||
client may directly start with a new REGISTER_REQ message.
|
||||
|
||||
==== Sync Request
|
||||
|
||||
When the client has received a Challenge but sees an invalid sequence number
|
||||
(embedded in AUTN, according to the milenage algorithm), the client may send a
|
||||
SYNC_REQ message containing an AUTS synchronisation token.
|
||||
|
||||
==== Sync Result
|
||||
|
||||
If the server has received a valid Sync Request, it shall answer by directly
|
||||
sending another Challenge (see <<oap-challenge>>). If an invalid Sync
|
||||
Request is received, the server shall reply with a REGISTER_ERR message.
|
||||
|
||||
==== Register Result
|
||||
|
||||
The server sends a REGISTER_RES message to indicate that registration has been
|
||||
successful. If the server cannot register the client (e.g. invalid challenge
|
||||
response), it shall send a REGISTER_ERR message.
|
||||
|
||||
=== Message Format
|
||||
|
||||
Every message is based on the following message format
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|===
|
||||
|
||||
The receiver shall be able to receive IEs in any order. Unknown IEs shall be
|
||||
ignored.
|
||||
|
||||
==== Register Request
|
||||
|
||||
Direction: Client -> Server
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|30|Client ID|<<common-oap-ie-clientid>>|M|TLV|4
|
||||
|===
|
||||
|
||||
==== Register Error
|
||||
|
||||
Direction: Server -> Client
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|02|Cause|GMM Cause, TS 04.08: 10.5.5.14|M|TLV|3
|
||||
|===
|
||||
|
||||
==== Register Result
|
||||
|
||||
Direction: Server -> Client
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|===
|
||||
|
||||
==== Challenge
|
||||
|
||||
Direction: Server -> Client
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|20|RAND|octet string (16)|TLV|18
|
||||
|23|AUTN|octet string (16)|TLV|18
|
||||
|===
|
||||
|
||||
==== Challenge Error
|
||||
|
||||
Direction: Client -> Server
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|02|Cause|GMM Cause, TS 04.08: 10.5.5.14|M|TLV|3
|
||||
|===
|
||||
|
||||
==== Challenge Result
|
||||
|
||||
Direction: Client -> Server
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|21|XRES|octet string (8)|TLV|10
|
||||
|===
|
||||
|
||||
==== Sync Request
|
||||
|
||||
Direction: Client -> Server
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|20|AUTS|octet string (16)|TLV|18
|
||||
|===
|
||||
|
||||
==== Sync Error
|
||||
|
||||
Direction: Server -> Client
|
||||
|
||||
[options="header",cols="5%,20%,60%,5%,5%,5%"]
|
||||
|===
|
||||
|IEI|IE|Type|Presence|Format|Length
|
||||
| |Message Type|<<common-oap-ie-msgtype>>|M|V|1
|
||||
|02|Cause|GMM Cause, TS 04.08: 10.5.5.14|M|TLV|3
|
||||
|===
|
||||
|
||||
=== Information Elements
|
||||
|
||||
[[common-oap-ie-msgtype]]
|
||||
==== Message Type
|
||||
|
||||
[options="header",cols="15%,85%"]
|
||||
|===
|
||||
|0x04|Register Requst
|
||||
|0x05|Register Error
|
||||
|0x06|Register Result
|
||||
|0x08|Challenge Request
|
||||
|0x09|Challenge Error
|
||||
|0x0a|Challenge Result
|
||||
|0x0c|Sync Request
|
||||
|0x0d|Sync Error (not used)
|
||||
|0x0e|Sync Result (not used)
|
||||
|===
|
||||
|
||||
[[common-oap-iei]]
|
||||
==== IE Identifier (informational)
|
||||
|
||||
These are the standard values for the IEI.
|
||||
|
||||
[options="header",cols="15%,15%,70%"]
|
||||
|===
|
||||
|IEI|Info Element|Type
|
||||
|0x02|Cause|GMM Cause, 04.08: 10.5.5.14
|
||||
|0x20|RAND|Octet String
|
||||
|0x23|AUTN|Octet Strong
|
||||
|0x24|XRES|Octet String
|
||||
|0x25|AUTS|Octet String
|
||||
|0x30|Client ID|big endian integer, 16 bit
|
||||
|===
|
||||
|
||||
[[common-oap-ie-clientid]]
|
||||
==== Client ID
|
||||
|
||||
[packetdiag]
|
||||
----
|
||||
{
|
||||
colwidth = 32
|
||||
node_height = 24
|
||||
|
||||
0-7: Client ID IEI
|
||||
8-15: Length (2)
|
||||
16-31: Client ID (big endian)
|
||||
}
|
||||
----
|
||||
|
||||
The Client ID number shall be interpreted as an unsigned 16bit integer, where 0
|
||||
indicates an invalid / unset ID.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
[[port-numbers]]
|
||||
== Appendix A. Osmocom TCP/UDP Port Numbers
|
||||
|
||||
The Osmocom GSM system utilizes a variety of TCP/IP based protocols. The
|
||||
table below provides a reference as to which port numbers are used by
|
||||
which protocol / interface.
|
||||
|
||||
[[table.port]]
|
||||
.TCP/UDP port numbers
|
||||
[options="header",cols="10%,10%,40%,40%"]
|
||||
|===============
|
||||
|L4 Protocol|Port Number|Purpose|Software
|
||||
|TCP|2775|SMPP (SMS interface for external programs)|osmo-nitb
|
||||
|TCP|3002|A/bis/IP OML|osmo-bts, osmo-bsc, osmo-nitb
|
||||
|TCP|3003|A-bis/IP RSL|osmo-bts, osmo-bsc, osmo-nitb
|
||||
|TCP|4240|telnet (VTY)|osmo-pcu
|
||||
|TCP|4241|telnet (VTY)|osmo-bts
|
||||
|TCP|4242|telnet (VTY)|osmo-nitb, osmo-bsc
|
||||
|TCP|4243|telnet (VTY)|osmo-bsc_mgcp
|
||||
|TCP|4244|telnet (VTY)|osmo-bsc_nat
|
||||
|TCP|4245|telnet (VTY)|osmo-sgsn
|
||||
|TCP|4246|telnet (VTY)|osmo-gbproxy
|
||||
|TCP|4249|Control Interface|osmo-nitb, osmo-bsc
|
||||
|TCP|4250|Control Interface|osmo-bsc_nat
|
||||
|TCP|5000|A/IP|osmo-bsc, osmo-bsc_nat
|
||||
|UDP|2427|GSMTAP|osmo-pcu, osmo-bts
|
||||
|UDP|23000|GPRS-NS over IP default port|osmo-pcu, osmo-sgsn, osmo-gbproxy
|
||||
|===============
|
|
@ -0,0 +1,274 @@
|
|||
== Foreword
|
||||
|
||||
Digital cellular networks based on the GSM specification were designed
|
||||
in the late 1980ies and first deployed in the early 1990ies in Europe.
|
||||
Over the last 25 years, hundreds of networks were established globally
|
||||
and billions of subscribers have joined the associated networks.
|
||||
|
||||
The technological foundation of GSM was based on multi-vendor
|
||||
interoperable standards, first created by government bodies within CEPT,
|
||||
then handed over to ETSI, and now in the hands of 3GPP. Nevertheless,
|
||||
for the first 17 years of GSM technology, the associated protocol stacks
|
||||
and network elements have only existed in proprietary 'black-box'
|
||||
implementations and not as Free Software.
|
||||
|
||||
In 2008 Dieter Spaar and I started to experiment with inexpensive
|
||||
end-of-life surplus Siemens GSM BTSs. We learned about the A-bis
|
||||
protocol specifications, reviewed protocol traces and started to
|
||||
implement the BSC-side of the A-bis protocol as something originally
|
||||
called `bs11-abis`. All of this was 'just for fun', in order to learn
|
||||
more and to boldly go where no Free Software developer has gone before.
|
||||
The goal was to learn and to bring Free Software into a domain that
|
||||
despite its ubiquity had not yet seen and Free / Open Source software
|
||||
implementations.
|
||||
|
||||
`bs11-abis` quickly turned into `bsc-hack`, then 'OpenBSC' and into
|
||||
what is today known as its 'OsmoNITB' variant: A minimal implementation
|
||||
of all the required functionality of an entire GSM network, exposing
|
||||
A-bis towards the BTS. The project attracted more interested
|
||||
developers, and surprisingly quick also commercial interest,
|
||||
contribution and adoption. This added support for more BTS models
|
||||
|
||||
After having implemented the network-side GSM protocol stack in 2008 and
|
||||
2009, in 2010 the same group of people set out to create a
|
||||
telephone-side implementation of the GSM protocol stack. This
|
||||
established the creation of the Osmocom umbrella project, under which
|
||||
OpenBSC and the OsmocomBB projects were hosted.
|
||||
|
||||
Meanwhile, more interesting telecom standards were discovered and
|
||||
implemented, including TETRA professional mobile radio, DECT cordless
|
||||
telephony, GMR satellite telephony, some SDR hardware, a SIM card
|
||||
protocol tracer and many others.
|
||||
|
||||
It has been a most exciting ride during the last seven years. I
|
||||
wouldn't want to miss it under any circumstances.
|
||||
|
||||
-- Harald Welte, Osmocom.org and OpenBSC founder, January 2016.
|
||||
|
||||
|
||||
== Acknowledgements
|
||||
|
||||
My deep thanks to everyone who has contributed to Osmocom. The list of
|
||||
contributors is too long to mention here, but I'd like to call out the
|
||||
following key individuals and organizations, in no particular order:
|
||||
|
||||
* Dieter Spaar for being the most amazing reverse engineer I've met in
|
||||
my career
|
||||
* Holger Freyther for his many code contributions and for shouldering a
|
||||
lot of the maintenance work, setting up Jenkins - and being crazy
|
||||
enough to co-start sysmocom as a company with me ;)
|
||||
* Andreas Eversberg for taking care of Layer2 and Layer3 of
|
||||
OsmocomBB, and for his work on OsmoBTS and OsmoPCU
|
||||
* Sylvain Munaut for always tackling the hardest problems, particularly
|
||||
when it comes closer to the physical layer
|
||||
* Chaos Computer Club for providing us a chance to run real-world
|
||||
deployments with tens of thousands of subscribers every year
|
||||
* Bernd Schneider of Netzing AG for funding early ip.access nanoBTS support
|
||||
* On-Waves ehf for being one of the early adopters of OpenBSC and
|
||||
funding a never ending list of features, fixes and general improvement
|
||||
of pretty much all of our GSM network element implementations
|
||||
* sysmocom, for hosting and funding a lot of Osmocom development, the
|
||||
annual Osmocom Developer Conference and releasing this manual.
|
||||
* Jan Luebbe, Stefan Schmidt, Daniel Willmann, Pablo Neira, Nico Golde,
|
||||
Kevin Redon, Ingo Albrecht, Alexander Huemer, Alexander Chemeris, Max
|
||||
Suraev, Tobias Engel, Jacob Erlbeck, Ivan Kluchnikov, Alexander Huemer
|
||||
|
||||
May the source be with you!
|
||||
|
||||
-- Harald Welte, Osmocom.org and OpenBSC founder, January 2016.
|
||||
|
||||
|
||||
== Preface
|
||||
|
||||
First of all, we appreciate your interest in Osmocom software.
|
||||
|
||||
Osmocom is a Free and Open Source Software (FOSS) community that
|
||||
develops and maintains a variety of software (and partially also
|
||||
hardware) projects related to mobile communications.
|
||||
|
||||
Founded by people with decades of experience in community-driven FOSS
|
||||
projects like the Linux kernel, this community is built on a strong
|
||||
belief in FOSS methodology, open standards and vendor neutrality.
|
||||
|
||||
|
||||
=== FOSS lives by contribution!
|
||||
|
||||
If you are new to FOSS, please try to understand that this development
|
||||
model is not primarily about ``free of cost to the GSM network
|
||||
operator'', but it is about a collaborative, open development model. It
|
||||
is about sharing ideas and code, but also about sharing the effort of
|
||||
software development and maintenance.
|
||||
|
||||
If your organization is benefitting from using Osmocom software, please
|
||||
consider ways how you can contribute back to that community. Such
|
||||
contributions can be many-fold, for example
|
||||
|
||||
* sharing your experience about using the software on the public mailing
|
||||
lists, helping to establish best practises in using/operating it,
|
||||
* providing qualified bug reports, work-arounds
|
||||
* sharing any modifications to the software you may have made, whether
|
||||
bug fixes or new features, even experimental ones
|
||||
* providing review of patches
|
||||
* testing new versions of the related software, either in its current
|
||||
``master'' branch or even more experimental feature branches
|
||||
* sharing your part of the maintenance and/or development work, either
|
||||
by donating developer resources or by (partially) funding those people
|
||||
in the community who do.
|
||||
|
||||
|
||||
=== Osmocom and sysmocom
|
||||
|
||||
Some of the founders of the Osmocom project have established sysmocom as
|
||||
a company to provide products and services related to Osmocom.
|
||||
|
||||
sysmocom and its staff are the by far the largest developers and
|
||||
contributors to the Osmocom mobile network infrastructure projects.
|
||||
|
||||
As part of this work, sysmocom has also created the manual you are
|
||||
reading.
|
||||
|
||||
At sysmocom, we draw a clear line between what is the Osmocom FOSS
|
||||
project, and what is sysmocom as a commercial entity. Under no
|
||||
circumstances requires participation in the FOSS projects any commercial
|
||||
relationship with sysmocom as a company.
|
||||
|
||||
|
||||
=== Corrections
|
||||
|
||||
We have prepared this manual in the hope it will guide you through the
|
||||
process of installing, configuring and debugging your deployment of
|
||||
cellular network infrastructure elements using Osmocom software. If
|
||||
you do find errors, mistakes and/or omissions, or have any suggestions
|
||||
on missing topics, please do take the extra time and let us know.
|
||||
|
||||
|
||||
=== Legal disclaimers
|
||||
|
||||
==== Spectrum License
|
||||
|
||||
As GSM operates in licensed spectrum, please always double-check that
|
||||
you have all required licenses and that you do not transmit on any ARFCN
|
||||
that is not explicitly allocated to you by the applicable regulatory
|
||||
authority in your country.
|
||||
|
||||
WARNING: Depending on your jurisdiction, operating a radio transmitter
|
||||
without a proper license may be considered a felony under criminal law!
|
||||
|
||||
|
||||
==== Software License
|
||||
|
||||
The software developed by the Osmocom project and described in this
|
||||
manual is Free / Open Source Software (FOSS) and subject to so-called
|
||||
_copyleft_ licensing.
|
||||
|
||||
Copyleft licensing is a legal instrument to ensure that this software
|
||||
and any modifications, extensions or derivative versions will always be
|
||||
publicly available to anyone, for any purpose, under the same terms as
|
||||
the original program as developed by Osmocom.
|
||||
|
||||
This means that you are free to use the software for whatever purpose,
|
||||
make copies and distribute them - just as long as you ensure to always
|
||||
provide/release the _complete and corresponding_ source code.
|
||||
|
||||
Every Osmocom software includes a file called `COPYING` in its source
|
||||
code repository which explains the details of the license. The majority
|
||||
of programs is released under GNU Affero General Public License, Version
|
||||
3 (AGPLv3).
|
||||
|
||||
If you have any questions about licensing, don't hesitate to contact the
|
||||
Osmocom community. We're more than happy to clarify if your intended
|
||||
use case is compliant with the software licenses.
|
||||
|
||||
|
||||
==== Trademarks
|
||||
|
||||
All trademarks, service marks, trade names, trade dress, product names
|
||||
and logos appearing in this manual are the property of their respecitve
|
||||
owners. All rights not expressly granted herein are reserved.
|
||||
|
||||
For your convenience we have listed below some of the registrered
|
||||
trademarks referenced herein. This is not a definitive or complete list
|
||||
of the trademarks used.
|
||||
|
||||
'Osmocom(R)' and 'OpenBSC(R)' are registered trademarks of Holger
|
||||
Freyther and Harald Welte.
|
||||
|
||||
'sysmocom(R)' and 'sysmoBTS(R)' is registered trasdemarks of
|
||||
'sysmocom - systems for mobile communications GmbH'.
|
||||
|
||||
'ip.access(R)' and 'nanoBTS(R)' are registered trademarks of
|
||||
'ip.access Ltd.'
|
||||
|
||||
|
||||
==== Liability
|
||||
|
||||
The software is distributed in the hope that it will be useful, but
|
||||
WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the License
|
||||
text included with the software for more details.
|
||||
|
||||
|
||||
==== Documentation License
|
||||
|
||||
Please see <<licenses-gfdl>> for further information.
|
||||
|
||||
|
||||
== Introduction
|
||||
|
||||
Please note that even while the capital expenses of running mobile
|
||||
networks has decreased significantly due to Osmocom software and
|
||||
associated hardware like sysmoBTS, GSM networks are still primarily
|
||||
operated by large GSM operators.
|
||||
|
||||
Neither the GSM specification nor the GSM equipment was ever designed
|
||||
for networks to be installed and configured by anyone but professional
|
||||
GSM engineers, specialized in their respective area like radio planning,
|
||||
radio access network, back-haul or core network.
|
||||
|
||||
If you do not share an existing background in GSM network architecture,
|
||||
GSM protocols, correctly installing, configuring and optimizing your GSM
|
||||
network will be tough, irrespective whether you use products with
|
||||
Osmocom software or those of traditional telecom suppliers.
|
||||
|
||||
GSM knowledge has many different fields, from radio planning through
|
||||
site installation through to core network configuration/administration.
|
||||
|
||||
The detailed skills required will depend on the type of installation
|
||||
and/or deployment that you are planning, as well as its associated
|
||||
network architecture. A small laboratory deployment for research at a
|
||||
university is something else than a rural network for a given village
|
||||
with a handful of cells, which is again entirely different from an urban
|
||||
network in a dense city.
|
||||
|
||||
Some of the useful skills we recommend are:
|
||||
|
||||
* general understanding about RF propagation and path loss in order to
|
||||
estimate coverage of your cells and do RF network planning.
|
||||
* general understanding about GSM network architecture, its network
|
||||
elements and key transactions on the Layer 3 protocol
|
||||
* general understanding about voice telephony, particularly those of
|
||||
ISDN heritage (Q.931 call control)
|
||||
* understanding of GNU/Linux system administration and working on the
|
||||
shell
|
||||
* understanding of TCP/IP networks and network administration, including
|
||||
tcpdump, tshark, wireshark protocol analyzers.
|
||||
* ability to work with text based configuration files and command-line
|
||||
based interfaces such as the VTY of the Osmocom network elements
|
||||
|
||||
|
||||
=== Getting assistance
|
||||
|
||||
If you do have a support package / contract with sysmocom (or want to
|
||||
get one), please contact us at support@sysmocom.de with any issues you
|
||||
may have.
|
||||
|
||||
If you don't have a support package / contract, please be advised that
|
||||
sysmocom can only provide very basic assistance. However, in any case,
|
||||
you can try to use the resources put together by the Osmocom community
|
||||
at http://openbsc.osmocom.org/, checking out the wiki and
|
||||
the mailing-list for community-based assistance. Please always
|
||||
remember, though: The community has no obligation to help you, and you
|
||||
should address your requests politely to them. The information (and
|
||||
software) provided at osmocom.org is put together by volunteers for
|
||||
free. Treat them like a friend whom you're asking for help, not like a
|
||||
supplier from whom you have bought a service.
|
|
@ -0,0 +1,699 @@
|
|||
== Introduction into RF Electronics
|
||||
|
||||
Setup and Operation of a GSM network is not only about the configuration
|
||||
and system administration on the network elements and protocol stack,
|
||||
but also includes the physical radio transmission part.
|
||||
|
||||
Basic understanding about RF (Radio Frequency) Electronics is key to
|
||||
achieving good performance of the GSM network.
|
||||
|
||||
[[rf-coaxial-cabling]]
|
||||
=== Coaxial Cabling
|
||||
|
||||
Coaxial cables come in many different shapes, diameters, physical
|
||||
construction, dielectric materials, and last but not least brands and
|
||||
types.
|
||||
|
||||
There are many parameters that might be relevant to your particular
|
||||
installation, starting from mechanical/environmental properties such as
|
||||
temperature range, UV resilience, water/weatherproofness, flammability,
|
||||
etc.
|
||||
|
||||
For the subject of this manual, we will not look at those mechanical
|
||||
properties, but look at the electrical properties instead.
|
||||
|
||||
The prime electrical parameters of a coaxial cable are:
|
||||
|
||||
* its attenuation over frequency and length
|
||||
* its maximum current/power handling capability
|
||||
* its propagation velocity (ignored here)
|
||||
* its screening efficiency (ignored here)
|
||||
|
||||
==== Coaxial Cable Attenuation
|
||||
|
||||
The attenuation of a coaxial cable is given in dB per length, commonly
|
||||
in 'dB per 100m'. This value changes significantly depending on the
|
||||
frequency of the signal transmitted via the cable. Cable manufacturers
|
||||
typically either provide tables with discrete frequency values, or
|
||||
graphs plotting the attenuation per 100m (x axis) over the frequency (y
|
||||
axis).
|
||||
|
||||
FIXME: Example.
|
||||
|
||||
So in order to estimate the loss of a coaxial cable, you need to
|
||||
|
||||
. determine the frequency at which you will use the cable, as determined
|
||||
by the GSM frequency band of your BTS. Make sure you use the highest
|
||||
frequency that might occur, which is typically the upper end of the
|
||||
transmit band, see <<gsm-bands>>
|
||||
. determine the attenuation of your cable per 100m at the given
|
||||
frequency (check the cable data sheet)
|
||||
. scale that value by the actual length of the cable
|
||||
|
||||
A real cable always has connectors attached to it, please add some
|
||||
additional losses for the connectors that are attached. 0.05 dB per
|
||||
connector is a general rule of thumb for the frequencies used in GSM.
|
||||
|
||||
FIXME: Example computation
|
||||
|
||||
As you can see very easily, the losses incurred in coaxial cables
|
||||
between your antenna and the BTS can very quickly become significant
|
||||
factors in your overall link budget (and thus cell coverage). This is
|
||||
particularly relevant for the uplink power budget. Every dB you loose
|
||||
in the antenna cable between antenna and the BTS receiver translates
|
||||
into reduced uplink coverage.
|
||||
|
||||
Using the shortest possible coaxial cabling (e.g. by mounting the BTS
|
||||
high up on the antenna tower) and using the highest-quality cabling are
|
||||
the best strategies to optimize
|
||||
|
||||
WARNING: If you plan to assemble the coaxial connectors yourself, please
|
||||
make sure you ensure to have the right skills for this. Properly
|
||||
assembling coaxial connectors (whether solder-type or crimp-type)
|
||||
requires precision tools and strict process as described by the
|
||||
manufacturer. Any mechanical imprecision of connector assembly will
|
||||
cause significant extra signal attenuation.
|
||||
|
||||
==== Checking coaxial cables
|
||||
|
||||
If you would like to check the proper operation of a coaxial cable,
|
||||
there are several possible methods available:
|
||||
|
||||
* The more expensive method would be to use a 'RF Network Analyzer' to
|
||||
measure the S11/S12 parameters or the VSWR of the cable.
|
||||
* Another option is to use a TDR (time domain reflectometer) to
|
||||
determine the VSWR. The TDR method has the added advantage that you
|
||||
can localize any damage to the cable, as such damage would cause
|
||||
reflections that can be converted into meters cable length from the
|
||||
port at which you are testing the cable. Mobile, battery-powered TDR
|
||||
for field-use in GSM Site installation are available from various
|
||||
vendors. One commonly used series is the 'Anritsu Site Master'.
|
||||
|
||||
|
||||
[[rf-coaxial-connectors]]
|
||||
=== Coaxial Connectors
|
||||
|
||||
A coaxial connector is a connector specifically designed for mounting to
|
||||
coaxial cable. It facilitates the removable / detachable connection of
|
||||
a coaxial cable to a RF device.
|
||||
|
||||
There are many different types of coaxial connectors on the market.
|
||||
|
||||
The most important types of coaxial connectors in the context of GSM
|
||||
BTSs are:
|
||||
|
||||
* The 'N type' connector
|
||||
* The 'SMA type' connector.
|
||||
* The '7/16' type connector
|
||||
|
||||
FIXME: Images
|
||||
|
||||
The above connectors are tightened by a screw-on shell. Each connector
|
||||
type has a specific designated nominal torque by which the connector
|
||||
shall be tightened. In case of uncertainty, please ask your connector
|
||||
supplier for the nominal torque.
|
||||
|
||||
NOTE: Always ensure the proper mechanical condition of your RF
|
||||
connectors. Don't use RF connectors that are contaminated by dust or
|
||||
dirt, or which show significant oxidization, bent contacts or the like.
|
||||
Using such connectors poses significant danger of unwanted signal loss,
|
||||
and can in some cases even lead to equipment damage (e.g. in case of RF
|
||||
power at PA output being reflected back into the PA).
|
||||
|
||||
|
||||
[[rf-duplexers]]
|
||||
=== Duplexers
|
||||
|
||||
A GSM BTS (or GSM TRX inside a BTS) typically exposes separate ports for
|
||||
Rx (Receive) and Tx (Transmit). This is intentionally the case, as
|
||||
this allows the users to add e.g. additional power amplifiers, filters
|
||||
or other external components into the signal path. Those components
|
||||
typically operate on either the receive or the transmit path.
|
||||
|
||||
You could now connect two separate antennas to the two ports (one for
|
||||
Rx, one for Tx). This is commonly done in indoor installations with
|
||||
small rubber-type antennas directly attached to the BTS connectors.
|
||||
|
||||
In outdoor installations, you typically (want to) use a single Antenna
|
||||
for Rx and Tx. This single antenna needs to be connected to the BTS
|
||||
via a device that is called 'Duplexer'.
|
||||
|
||||
The 'Duplexer' is actually a frequency splitter/combiner, which is
|
||||
specifically tuned to the uplink and downlink frequencies of the GSM
|
||||
band in which you operate the BTS. As such, it has one port that passes
|
||||
only uplink frequencies between the antenna and that port, as well as
|
||||
another port that passes only downlink frequencies between antenna and
|
||||
that port.
|
||||
|
||||
.Illustration of the Duplexer functionality
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir = LR;
|
||||
|
||||
BTS -> Duplexer [label="Tx band"];
|
||||
Duplexer [shape=box];
|
||||
Duplexer -> BTS [label="Rx band"];
|
||||
Duplexer -> Antenna [label ="All frequencies",dir=both];
|
||||
Antenna [shape=cds];
|
||||
}
|
||||
----
|
||||
|
||||
WARNING: *The ports of a duplexer are not interchangeable*. Always make
|
||||
sure that you use the Rx port of the duplexer with the Rx port of the
|
||||
BTS, and vice-versa for Tx.
|
||||
|
||||
|
||||
[[rf-pa]]
|
||||
=== RF Power Amplifiers
|
||||
|
||||
A RF Power Amplifier (PA) is a device that boosts the transmit power of
|
||||
your RF signal, the BTS in your case.
|
||||
|
||||
RF power amplifiers come in many different characteristics. Some of the
|
||||
key characteristics are:
|
||||
|
||||
Frequency range::
|
||||
A PA is typically designed for a specific frequency range. Only
|
||||
signals inside that range will be properly amplified
|
||||
Gain in dB::
|
||||
This tells you how many dB the power amplifier will increase your
|
||||
signal. `Pout = Pin + Gain`
|
||||
Maximum Output Power::
|
||||
This indicates the maximum absolute output power. For example, if the
|
||||
maximum output power is 40 dBm, and the gain is 10dBm, then an input
|
||||
signal of 30dBm will render the maximum output power. An input signal
|
||||
of 20dBm would subsequently generate only 30dBm of output power.
|
||||
Efficiency::
|
||||
The efficiency determines how much electrical power is consumed for
|
||||
the given output power. Often expressed as Power Added Efficiency
|
||||
(PAE).
|
||||
|
||||
WARNING: If you add external power amplifiers to a GSM BTS or any other
|
||||
transmitter, this will invalidate the regulatory approval of the BTS.
|
||||
It is your responsibility to ensure that the combination of BTS and PA
|
||||
still fulfills all regulatory requirements, for example in terms of
|
||||
out-of-band emissions, spectrum envelope, phase error, linearity, etc!
|
||||
|
||||
[graphviz]
|
||||
.Addition of a RF Power Amplifier to a GSM BTS Setup
|
||||
----
|
||||
digraph G {
|
||||
rankdir = LR;
|
||||
BTS;
|
||||
PA [label="PA 14dB gain"];
|
||||
Duplexer [shape=box];
|
||||
|
||||
BTS -> PA [label="Tx 23 dBm"];
|
||||
PA -> Duplexer [label="Tx 37dBm"];
|
||||
Duplexer -> BTS [label="Rx band"];
|
||||
Duplexer -> Antenna [dir=both];
|
||||
Antenna [shape=cds];
|
||||
}
|
||||
----
|
||||
|
||||
|
||||
=== Antennas
|
||||
|
||||
The Antenna is responsible for converting the electromagnetic waves
|
||||
between the coaxial cable and the so-called 'air interface' and
|
||||
vice-versa. The properties of an antenna are always symmetric for both
|
||||
transmission and reception.
|
||||
|
||||
Antennas come in many different types and shapes. Key characteristics
|
||||
distinguishing antennas are:
|
||||
|
||||
Antenna Gain::
|
||||
Expresses how much more efficient the antenna converts between cable
|
||||
and air interface. Can be expressed in dB compared to a theoretical
|
||||
isotropic radiator (dBi) or compared to a dipole antenna (dBd). Gain
|
||||
usually implies directivity.
|
||||
|
||||
Frequency Band(s)::
|
||||
Antennas typically have only a relatively narrow band (or multiple
|
||||
narrow bands at which they radiate efficiently. In general, the
|
||||
higher the antenna gain, the lower the usable frequency band of the
|
||||
antenna.
|
||||
|
||||
Directivity::
|
||||
Antennas radiate the energy in all three dimensions.
|
||||
|
||||
Mechanical Size::
|
||||
Mechanical Size is an important factor depending on how and where the
|
||||
antenna is mounted. Size also relates to weight and wind-load.
|
||||
|
||||
Wind Load::
|
||||
Expresses how much mechanical load the antenna will put on its
|
||||
support structure (antenna mast).
|
||||
|
||||
Connector Type::
|
||||
Your cabling will have to use a compatible connector for the antenna.
|
||||
Outdoor antennas typically use the 7/16 type connector or an N type
|
||||
connector. Indoor antennas either N type or SMA type.
|
||||
|
||||
Environmental Rating::
|
||||
Indoor antennas cannot be used outdoor, as they do not offer the level
|
||||
of protection against dust and particularly water / humidity /
|
||||
corrosion.
|
||||
|
||||
Down-tilt Capability::
|
||||
Particularly sector antennas are typically installed with a fixed or
|
||||
(mechanically / electrically) variable down-tilt in order to limit the
|
||||
radius/horizon of the antenna footprint and avoid excess interference
|
||||
with surrounding cells.
|
||||
|
||||
VSWR::
|
||||
The Voltage Standing Wave Ratio indicates how well the antenna is
|
||||
matched to the coaxial cable, and how much of the to-be-transmitted
|
||||
radio signal is actually converted to radio waves versus reflected
|
||||
back on the RF cable towards the transmitter. An ideal antenna has a
|
||||
VSWR of 1 (sometimes written 1:1). Real antennas are typically in the
|
||||
range of 1.2 to 2.
|
||||
|
||||
Side Lobes::
|
||||
A directional antenna never radiates only in one direction but always
|
||||
has certain side lobes pointing outside of the main direction of the
|
||||
antenna. The number and strength of side lobes differ from antenna
|
||||
to antenna model.
|
||||
|
||||
NOTE: Whenever installing antennas it is important to understand that
|
||||
any metallic or otherwise conductive object in their vicinity will
|
||||
inevitably alter the antenna performance. This can affect the radiation
|
||||
pattern, but also de-tune the antenna and shift its frequency band
|
||||
outside the nominal usable frequency band. It is thus best to mount
|
||||
antennas as far as practically possible from conductive elements within
|
||||
their radiation pattern
|
||||
|
||||
|
||||
==== Omni-directional Antennas
|
||||
|
||||
Omni-directional antennas are typically thin long dipole antennas covered
|
||||
with fiberglass. They radiate with equal strength in all directions and
|
||||
thus result in a more or less circular cell footprint (assuming flat
|
||||
terrain). The shape of the radiation pattern is a torus (donut) with
|
||||
the antenna located in the center of that torus.
|
||||
|
||||
Omni-directional antennas come with a variety of gains, typically from 0
|
||||
dBd to 3 dBd, 6 dBd and sometimes 9 dBd. This gain is achieved by
|
||||
compressing the radiation torus in the vertical plane.
|
||||
|
||||
Sometimes, Omni-directional antennas can be obtained with a fixed
|
||||
down-tilt to limit the cell radius.
|
||||
|
||||
|
||||
==== Sector Antennas
|
||||
|
||||
Sector antennas are used in sectorized cell setups. Sector antennas can
|
||||
have significantly higher gain than omni-directional antennas.
|
||||
|
||||
Instead of mounting a single BTS with an omni-directional antenna to a
|
||||
given antenna pole, multiple BTSs with each one sector antenna are
|
||||
mounted to the same pole. This results in an overall larger radius due
|
||||
to the higher gain of the sector antennas, and also in an overall
|
||||
capacity increase, as each sector has the same capacity as a single
|
||||
omni-directional cell. And all that benefit still requires only a
|
||||
single physical site with antenna pole, power supply, back-haul cabling,
|
||||
etc.
|
||||
|
||||
Experimentation and simulation has shown that typically the use of three
|
||||
sectors with antennas of an opening angle of 65 degrees results in the
|
||||
most optimal combination for GSM networks. If more sectors are being
|
||||
deployed, there is a lot of overlap between the sectors, and the amount
|
||||
of hand-overs between the BTSs is increased.
|
||||
|
||||
|
||||
|
||||
[[rf-lna]]
|
||||
=== RF Low Noise Amplifier (LNA)
|
||||
|
||||
A RF Low Noise Amplifier (LNA) is a device that amplifies the weak
|
||||
received signal. In general, LNAs are combined with band filters, to
|
||||
ensure that only those frequencies within the receive band are
|
||||
amplified, and out-of-band interferers are filtered out. A duplexer
|
||||
can already be a sufficient band-filter, depending on its
|
||||
characteristics.
|
||||
|
||||
The use of a LNA typically only makes sense if you
|
||||
. have very long and/or lossy coaxial cables from your antenna to the
|
||||
BTS, and
|
||||
. can mount the duplexer + LNA close to the antenna, so that the
|
||||
amplification happens before the long/lossy coaxial line to the BTS
|
||||
|
||||
Key characteristics of a LNA are:
|
||||
|
||||
Frequency range::
|
||||
A LNA is typically designed for a specific frequency range. Only
|
||||
signals inside that range will be properly amplified
|
||||
Gain in dB::
|
||||
This tells you how many dB the low noise amplifier will increase your
|
||||
signal. `Pout = Pin + Gain`
|
||||
Maximum Input Power::
|
||||
This indicates the maximum RF power at the PA input before saturation.
|
||||
Noise Figure::
|
||||
This indicates how much noise this LNA will add to the signal. This
|
||||
noise will add to the interference as seen by the receiver.
|
||||
|
||||
[graphviz]
|
||||
.Addition of a RF Low Noise Amplifier to the GSM BTS Setup
|
||||
----
|
||||
digraph G {
|
||||
rankdir = LR;
|
||||
|
||||
BTS -> LNA [label="Rx",dir=back];
|
||||
LNA -> Duplexer [label="Rx",dir=back];
|
||||
BTS -> Duplexer [label="Tx"];
|
||||
Duplexer -> Antenna [dir=both];
|
||||
|
||||
Duplexer [shape=box];
|
||||
Antenna [shape=cds];
|
||||
}
|
||||
----
|
||||
|
||||
[graphviz]
|
||||
.Addition of a RF LNA + RF PA to the GSM BTS Setup
|
||||
----
|
||||
digraph G {
|
||||
rankdir = LR;
|
||||
|
||||
subgraph {
|
||||
rank = same;
|
||||
PA;
|
||||
LNA;
|
||||
}
|
||||
|
||||
BTS -> LNA [label="Rx",dir=back];
|
||||
BTS -> PA [label="Tx 23 dBm"];
|
||||
LNA -> Duplexer [label="Rx",dir=back];
|
||||
PA -> Duplexer [label="Tx 37 dBm"];
|
||||
Duplexer -> Antenna [dir=both];
|
||||
|
||||
PA [label="PA 14dB gain"];
|
||||
Duplexer [shape=box];
|
||||
Antenna [shape=cds];
|
||||
}
|
||||
----
|
||||
|
||||
As any LNA will add noise to the signal, it is generally discouraged to
|
||||
add them to the system. Instead, we recommend you to mount the entire
|
||||
BTS closer to the antenna, thereby removing the losses created by
|
||||
lengthy coaxial wire. The power supply lines and Ethernet connection to
|
||||
the BTS are far less critical when it comes to cable length.
|
||||
|
||||
|
||||
== Introduction into GSM Radio Planning
|
||||
|
||||
The main focus of the manual you are reading is to document the
|
||||
specifics of the Osmocom GSM implementation in terms of configuration,
|
||||
system administration and monitoring. That's basically all on the
|
||||
software part.
|
||||
|
||||
However, successful deployment and operation of GSM networks depends to
|
||||
a large extent on the proper design on the radio frequency (RF) side,
|
||||
including the right cabling, duplexers, antennas, etc.
|
||||
|
||||
Planning and implementing GSM deployment is a science (or art) in
|
||||
itself, and in most cases it is best to consult with somebody who has
|
||||
existing experience in the field.
|
||||
|
||||
There are three parts to this:
|
||||
|
||||
GSM Radio Network Planning::
|
||||
This includes an analysis of the coverage area, its terrain/geography,
|
||||
the selection of the right sites for your BTSs, the antenna height, a
|
||||
path loss estimate. As a result of that process, it will be clear
|
||||
what amount of transmit power, antenna gain, cable length/type, etc.
|
||||
you should use to obtain the intended coverage.
|
||||
GSM Site Installation::
|
||||
This is the execution of what has been determined in the previous
|
||||
step. The required skills are quite different, as this is about
|
||||
properly assembling RF cables and connections, duplexers, power
|
||||
amplifiers, antennas, etc.
|
||||
Coverage testing::
|
||||
This is typically done by driving or walking in the newly-deployed GSM
|
||||
site, and checking of the coverage is as it was expected.
|
||||
|
||||
NOTE: This chapter can only give you the briefest overview about the
|
||||
process used, and cannot replace the experience and skill of somebody
|
||||
with GSM RF planning and site deployment.
|
||||
|
||||
[[rf-radio-net-plan]]
|
||||
=== GSM Radio Network Planning
|
||||
|
||||
In GSM Radio Network Planning, the number and location of sites as well
|
||||
as type of required equipment is determined based on the coverage
|
||||
requirements.
|
||||
|
||||
For the coverage of a single BTS, this is a process that takes into
|
||||
consideration:
|
||||
|
||||
* the terrain that needs to be covered
|
||||
* the type of mobile stations to be supported, and particularly the
|
||||
speed of their movement (residential, pedestrians, trains, highways)
|
||||
* the possible locations for cell sites, where BTSs and Antennas can be
|
||||
placed, as well as the possible antenna mounting height
|
||||
* the equipment choices available, including
|
||||
** type and capabilities of BTS. The key criteria here is
|
||||
the downlink transmit power in dBm, and the uplink receive
|
||||
sensitivity.
|
||||
** antenna models, including gain, radiation pattern, etc.
|
||||
** RF cabling, including the key aspect of attenuation per length
|
||||
** RF duplexers, splitting the transmit and receive path
|
||||
** power amplifiers (PAs), increasing the transmit power
|
||||
** low noise amplifiers (LNAs), amplifying the received signal
|
||||
|
||||
For coverage of an actual cellular network consisting of neighboring
|
||||
cells, this process also must take into consideration aspects of
|
||||
'frequency planning', which is the allocation of frequencies (ARFCNs) to
|
||||
the individual cells within the network. As part of that, interference
|
||||
generated by frequency re-use of other (distant) cells must be taken
|
||||
into consideration. The details of this would go beyond this very
|
||||
introductory text. There is plenty of literature on this subject
|
||||
available.
|
||||
|
||||
[[rf-db]]
|
||||
=== The Decibel (dB) and Decibel-Milliwatt (dBm)
|
||||
|
||||
RF engineering heavily depends on the Decibel (dB) as a unit to express
|
||||
attenuation (losses) or amplification (gain) impacted on radio signals.
|
||||
|
||||
The dB is a logarithmic unit, it is used to express the ratio of two
|
||||
values of physical quantity. You can thus not express an absolute value
|
||||
in dB, only relative.
|
||||
|
||||
NOTE: *Relative loss* (cable, connector, duplexer, splitter) *or gain*
|
||||
(amplifiers) are power *is expressed in dB*.
|
||||
|
||||
In order to express an absolute value, you need to use a unit like
|
||||
'dBm', which is referencing a power of 1 mW (milli-Watt).
|
||||
|
||||
NOTE: *Absolute power* like transmitter output power or receiver input
|
||||
power *is expressed in dBm*.
|
||||
|
||||
[options="header",cols="15%,15%,70%"]
|
||||
.Example table of dBm values and their corresponding RF Power
|
||||
|===
|
||||
|dBm|RF Power|Comment
|
||||
|0|1 mW|
|
||||
|1|1.26 mW|transmit power of sysmoBTS 1002 when used with `max_power_red 22`
|
||||
|3|2 mW|
|
||||
|6|4 mW|
|
||||
|12|16 mW|
|
||||
|12|16 mW|
|
||||
|20|100 mW|
|
||||
|23|199 mW|Maximum transmit power of indoor sysmoBTS 1002
|
||||
|26|398 mW|
|
||||
|30|1 W|Maximum transmit power of a MS in 1800/1900 MHz band
|
||||
|33|2 W|Maximum transmit power of a MS in 850/900 MHz band
|
||||
|37|5 W|Maximum transmit power of 1 TRX in sysmoBTS 2050
|
||||
|40|10 W|Maximum transmit power of sysmoBTS 1100
|
||||
|===
|
||||
|
||||
[[rf-gsm-bands]]
|
||||
=== GSM Frequency Bands
|
||||
|
||||
GSM can operate in a variety of frequency bands. However,
|
||||
internationally only the following four bands have been deployed in
|
||||
actual networks:
|
||||
|
||||
[options="header"]
|
||||
.Table of GSM Frequency Bands
|
||||
|===
|
||||
|Name|Uplink Band|Downlink Band|ARFCN Range
|
||||
|GSM 850|824 MHz .. 849 MHz|869 MHz .. 894 MHz|128 .. 251
|
||||
|E-GSM 900|880 MHz .. 915 MHz|925 MHz .. 960 MHz|0 .. 124, 975 .. 1023
|
||||
|DCS 1800|1710 MHz .. 1785 MHz|1805 MHz .. 1880 MHz|512 .. 885
|
||||
|PCS 1900|1850 MHz .. 1910 MHz|1930 MHz .. 1990 MHz|512 .. 810
|
||||
|===
|
||||
|
||||
[[rf-path-loss]]
|
||||
=== Path Loss
|
||||
|
||||
A fundamental concept in planning any type of radio communications link
|
||||
is the concept of 'Path Loss'. Path Loss describes the amount of
|
||||
signal loss (attenuation) between a receive and a transmitter.
|
||||
|
||||
As GSM operates in frequency duplex on uplink and downlink, there is
|
||||
correspondingly an 'Uplink Path Loss' from MS to BTS, and a 'Downlink
|
||||
Path Loss' from BTS to MS. Both need to be considered.
|
||||
|
||||
It is possible to compute the path loss in a theoretical ideal
|
||||
situation, where transmitter and receiver are in empty space, with no
|
||||
surfaces anywhere nearby causing reflections, and with no objects or
|
||||
materials in between them. This is generally called the 'Free Space
|
||||
Path Loss'.
|
||||
|
||||
Estimating the path loss within a given real-world terrain/geography is
|
||||
a hard problem, and there are no easy solutions. It is impacted, among
|
||||
other things, by
|
||||
|
||||
* the height of the transmitter and receiver antennas
|
||||
* whether there is line-of-sight (LOS) or non-line-of-sight (NLOS)
|
||||
* the geography/terrain in terms of hills, mountains, etc.
|
||||
* the vegetation in terms of attenuation by foliage
|
||||
* any type of construction, and if so, the type of materials used in
|
||||
that construction, the height of the buildings, their distance, etc.
|
||||
* the frequency (band) used. Lower frequencies generally expose better
|
||||
NLOS characteristics than higher frequencies.
|
||||
|
||||
The above factors determine on the one hand side the actual attenuation
|
||||
of the radio wave between transmitter and receiver. On the other
|
||||
hand, they also determine how many reflections there are on this path,
|
||||
causing so-called 'Multipath Fading' of the signal.
|
||||
|
||||
Over decades, many different radio propagation models have been designed
|
||||
by scientists and engineers. They might be based on empirical studies
|
||||
condensed down into relatively simple models, or they might be based on
|
||||
ray-tracing in a 3D model of the terrain.
|
||||
|
||||
Several companies have developed (expensive, proprietary) simulation
|
||||
software that can help with this process in detail. However, the
|
||||
results of such simulation also depend significantly on the availability
|
||||
of precise 3D models of the geography/terrain as well as the building
|
||||
structure in the coverage area.
|
||||
|
||||
In absence of such simulation software and/or precise models, there are
|
||||
several models that can help, depending on the general terrain:
|
||||
|
||||
[[path-loss-models]]
|
||||
.List of common path loss models
|
||||
[options="header",cols="20%,20%,60%"]
|
||||
|===
|
||||
|Type|Sub-Type|Bands|Name
|
||||
|Terrain|-|850, 900, 1800, 1900|ITU terrain model
|
||||
|Rural|Foliage|850, 900, 1800, 1900|One woodland terminal model
|
||||
|City|Urban|850, 900|Okumura-Hata Model for Urban Areas
|
||||
|City|Suburban|850, 900|Okumura-Hata Model for Suburban Areas
|
||||
|City|Open|850, 900|Okumura-Hata Model for Open Areas
|
||||
|City|Urban|1800, 1900|COST-231 Hata Model
|
||||
|Indoor|-|900, 1800, 1900|ITU model for indoor attenuation
|
||||
|===
|
||||
|
||||
In <<path-loss-models>> you can see a list of commonly-used path loss
|
||||
models. They are typically quite simple equations which only require
|
||||
certain parameters like the distance of transmitter and receiver as well
|
||||
as the antenna height, etc. No detailed 3D models of the terrain are
|
||||
required.
|
||||
|
||||
FIXME: Example calculations
|
||||
|
||||
[[rf-link-budget]]
|
||||
=== Link Budget
|
||||
|
||||
The link budget consists of the total budget of all elements in the
|
||||
telecommunication system between BTS and MS (and vice-versa).
|
||||
|
||||
This includes
|
||||
|
||||
* antenna gains on both sides
|
||||
* coaxial cabling between antenna and receiver/transmitter
|
||||
* losses in duplexers, splitters, connectors, etc
|
||||
* gain of any amplifiers (PA, LNA)
|
||||
* path loss of the radio link between the two antennas
|
||||
|
||||
The simplified link budget equations looks like this:
|
||||
|
||||
Rx Power (dBm) = Tx Power (dBm) + Gains (dB) − Losses (dB)
|
||||
|
||||
Gains is the sum of all gains, including
|
||||
|
||||
* Gain of the transmitter antenna
|
||||
* Gain of the receiver antenna
|
||||
* Gain of any PA (transmitter) or LNA (receiver)
|
||||
|
||||
Losses is the sum of all losses, including
|
||||
|
||||
* Loss of any cabling and/or connectors on either side
|
||||
* Loss of any passive components like duplexers/splitters on either side
|
||||
* Path Loss of the radio link
|
||||
|
||||
Using the Link Budget equation and resolving it for the path loss will
|
||||
give you an idea of how much path loss on the radio link you can afford
|
||||
while still having a reliable radio link. Resolving the path loss into
|
||||
a physical distance based on your path loss model will then give you an
|
||||
idea about the coverage area that you can expect.
|
||||
|
||||
The Rx Power substituted in the Link budget equation is determined by
|
||||
the receiver sensitivity. It is customary to add some some safety
|
||||
margin to cover for fading.
|
||||
|
||||
==== Uplink Link Budget
|
||||
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir = LR;
|
||||
MS -> MSAnt -> Path -> BTSAnt -> Cabling -> Duplexer -> Cable -> BTS;
|
||||
MSAnt [label="MS Antenna"];
|
||||
BTSAnt [label="BTS Antenna"];
|
||||
}
|
||||
----
|
||||
|
||||
The transmit power of a MS depends on various factors, such as the MS
|
||||
Power Class, the frequency band and the modulation scheme used.
|
||||
|
||||
[options="header"]
|
||||
.Typical MS transmit power levels
|
||||
|===
|
||||
|Power Class|Band|Modulation|Power
|
||||
|4|850 / 900|GMSK|33 dBm (2 W)
|
||||
|1|1800 / 1900|GMSK|30 dBm (1 W)
|
||||
|E2|850 / 900|8PSK|27 dBm (0.5 W)
|
||||
|E2|1800 / 1900|8PSK|26 dBm (0.4 W)
|
||||
|===
|
||||
|
||||
The minimum reference sensitivity level of a normal GSM BTS is specified
|
||||
in 3GPP TS 05.05 and required to be at least -104 dBm. Most modern BTSs
|
||||
outperform this significantly.
|
||||
|
||||
FIXME: Example calculation (spreadsheet screenshot?)
|
||||
|
||||
==== Downlink Link Budget
|
||||
|
||||
[graphviz]
|
||||
----
|
||||
digraph G {
|
||||
rankdir = LR;
|
||||
BTS -> Cable -> Duplexer -> Cabling -> BTSAnt -> Path -> MSAnt -> MS;
|
||||
MSAnt [label="MS Antenna"];
|
||||
BTSAnt [label="BTS Antenna"];
|
||||
}
|
||||
----
|
||||
|
||||
The transmit power of the BTS depends on your BTS model and any possible
|
||||
external power amplifiers used.
|
||||
|
||||
The minimum reference sensitivity level of a GSM MS is specified in 3GPP
|
||||
TS 05.05 and can typically be assumed to be about -102 dB.
|
||||
|
||||
FIXME: Example calculation (spreadsheet screenshot?)
|
||||
|
||||
|
||||
==== Optimization of the Link Budget
|
||||
|
||||
If the coverage area determined by the above procedure is insufficient,
|
||||
you can try to change some of the parameters, such as
|
||||
|
||||
* increasing transmit power by adding a bigger PA
|
||||
* increasing antenna gain by using a higher gain antenna
|
||||
* reducing cable losses by using better / shorter coaxial cables
|
||||
* increasing the height of your antenna
|
|
@ -0,0 +1,46 @@
|
|||
[[spectrum]]
|
||||
== Regulatory Requirements
|
||||
|
||||
=== Spectrum License Required
|
||||
|
||||
|
||||
GSM operates in licensed frequency spectrum. As a result you may not
|
||||
operate a BTS without having obtained a license from the regulatory
|
||||
authority in the country you want to operate the BTS in.
|
||||
|
||||
Failure to acquire a proper spectrum license or failure to comply with
|
||||
the terms of the license can lead to interference with public
|
||||
communications networks, which not only may cause civil claims by the
|
||||
operator of the interfered network, but is punishable as a crime under
|
||||
most jurisdictions.
|
||||
|
||||
sysmocom disclaims any responsibility for illegal / unlicensed use of
|
||||
its products.
|
||||
|
||||
|
||||
=== Regulatory authorities by country
|
||||
|
||||
|
||||
The following (by far incomplete) list gives you some indication of the
|
||||
regulatory authorities for the respective country. sysmocom does not
|
||||
guarantee correctness of this information.
|
||||
|
||||
[[table.reg]]
|
||||
.Regulatory authorities
|
||||
[options="header"]
|
||||
|===============
|
||||
|Country|Name
|
||||
|Austria|RTR
|
||||
|Belgium|IBPT
|
||||
|Germany|Bundesnetzagentur
|
||||
|Italy|AGCOM
|
||||
|Netherlands|Agentschap Telecom
|
||||
|Sweden|PTS
|
||||
|Switzerland|Bakom
|
||||
|United Kingdom|Ofcom
|
||||
|United States of America|FCC
|
||||
|===============
|
||||
|
||||
|
||||
A more complete list of regulatory authorities including links to their
|
||||
web pages can be found at https://en.wikipedia.org/wiki/List_of_telecommunications_regulatory_bodies
|
|
@ -0,0 +1,299 @@
|
|||
[[vty]]
|
||||
== The Osmocom VTY Interface
|
||||
|
||||
All interaction with Osmocom software is typically performed via an
|
||||
interactive command-line interface called the _VTY_.
|
||||
|
||||
The Osmocom VTY is used to
|
||||
|
||||
* explore the current status of the system, including its configuration
|
||||
parameters but also run-time state and statistics
|
||||
* review the currently active (running) configuration
|
||||
* perform interactive changes to the configuration
|
||||
* store the current running configuration to the config file
|
||||
* enable or disable logging; to the VTY itself or to other targets
|
||||
|
||||
The Virtual Tele Type (VTY) has the concept of __nodes__ and
|
||||
__commands__. Each command has a name and arguments. The name may
|
||||
contain a space to group several similar commands into a specific group.
|
||||
The arguments can be a single word, a string, numbers, ranges or a list
|
||||
of options. The available commands depend on the current node. there
|
||||
are various keyboard shortcuts to ease finding commands and the possible
|
||||
argument values.
|
||||
|
||||
This chapter explains the most common nodes nodes and the commands that
|
||||
are available within the node.
|
||||
|
||||
There are common patterns for the parameters, these include IPv4
|
||||
addresses, number ranges, a word, a line of text and choice. The
|
||||
following will explain the commonly used syntactical patterns:
|
||||
|
||||
.VTY Parameter Patterns
|
||||
[options="header",cols="35%,25%,40%"]
|
||||
|===============
|
||||
|Pattern|Example|Explanation
|
||||
|`A.B.C.D`|`127.0.0.1`|An IPv4 address
|
||||
|`TEXT`|`example01`|A single string without any spaces, tabs
|
||||
|`.TEXT`|`Some information`|A line of text
|
||||
|`(OptionA\|OptionB\|OptionC)`|`OptionA`|A choice between a list of available options
|
||||
|`<0-10>`|`5`|A number from a range
|
||||
|===============
|
||||
|
||||
=== Accessing the VTY
|
||||
|
||||
The VTY of a given Osmocom program is implemented as a telnet server,
|
||||
listening to a specific TCP port. For `osmo-nitb`, this port is `4242`.
|
||||
|
||||
Please see <<port-numbers>> to check for the default TCP port number of
|
||||
the VTY interface of the specific Osmocom software you would like to
|
||||
connect to.
|
||||
|
||||
As telnet is insecure and offers neither strong authentication nor
|
||||
encryption, the VTY by default only binds to localhost (127.0.0.1) and
|
||||
will thus not be reachable by other hosts on the network.
|
||||
|
||||
WARNING: By default, any user with access to the machine running the
|
||||
Osmocom software will be able to connect to the VTY. We assume that
|
||||
such systems are single-user systems, and anyone with local access to
|
||||
the system also is authorized to access the VTY. If you require
|
||||
stronger security, you may consider using the packet filter of your
|
||||
operating system to restrict access to the Osmocom VTY ports further.
|
||||
|
||||
|
||||
=== VTY Nodes
|
||||
|
||||
The VTY by default has the following minimal nodes:
|
||||
|
||||
VIEW::
|
||||
The 'VIEW' node is the node you automatically enter when you connect to
|
||||
a VTY. As its name implies, it can only be used to view the system
|
||||
status, but it does not provide commands to alter the system
|
||||
state or configuration. As long as you are in the non-privileged
|
||||
'VIEW' node, your prompt will end in a `>` character.
|
||||
|
||||
ENABLE::
|
||||
The 'ENABLE' node is entered as soon as you enter the `enable` command
|
||||
from the 'VIEW' node. Changing into the 'ENABLE' node will unlock all
|
||||
kinds of commands that allow you to alter the system state or perform
|
||||
any other change to it. The 'ENABLE' node and its children are
|
||||
signified by a '#' character at the end of your prompt.
|
||||
+
|
||||
You can change back from the 'ENABLE' node to the 'VIEW' node by using
|
||||
the `disable` command.
|
||||
|
||||
CONFIG::
|
||||
The 'CONFIG' node is entered when you enter the `configure terminal`
|
||||
command from the 'VIEW' node. The config node is used to change the
|
||||
run-time configuration parameters of teh system. The prompt will
|
||||
indicate that you are in the config node by a `(config)#` prompt
|
||||
suffix.
|
||||
+
|
||||
You can always leave the 'CONFIG' node or any of its children by using
|
||||
the `end` command.
|
||||
+
|
||||
This node is also automatically entered at the time the configuration
|
||||
file is read. All configuration file lines are processed as if they
|
||||
were entered from the VTY 'CONFIG' node at start-up.
|
||||
|
||||
Other::
|
||||
Depending on the specific Osmocom program you are running, there will
|
||||
be few or more other nodes, typically below the 'CONFIG' node. For
|
||||
example, the OsmoBSC has nodes for each BTS, and within the BTS node
|
||||
one for each TRX, and within the TRX node one for each Timeslot.
|
||||
|
||||
|
||||
=== Interactive help
|
||||
|
||||
The VTY features an interactive help system, designed to help you to
|
||||
efficiently navigate is commands.
|
||||
|
||||
NOTE: The VTY is present on most Osmcoom GSM/GPRS software, thus this
|
||||
chapter is present in all the relevant manuals. The detailed examples
|
||||
below assume you are executing them on the OsmoNITB VTY. They will work
|
||||
in similar fashion on the other VTY, too - but of course the output will
|
||||
be different for each program.
|
||||
|
||||
==== The question-mark (`?`) command
|
||||
|
||||
If you type a single `?` at the prompt, the VTY will display you
|
||||
possible completions at the exact location of your currently entered
|
||||
command.
|
||||
|
||||
If you type `?` at an otherwise empty command (without having entered
|
||||
even only a partial command), you will get a list of the first word of
|
||||
all possible commands available at this node:
|
||||
|
||||
.Example: Typing `?` at start of OsmoNITB prompt
|
||||
----
|
||||
OpenBSC> <1>
|
||||
show Show running system information
|
||||
list Print command list
|
||||
exit Exit current mode and down to previous mode
|
||||
help Description of the interactive help system
|
||||
enable Turn on privileged mode command
|
||||
terminal Set terminal line parameters
|
||||
who Display who is on vty
|
||||
logging Configure log message to this terminal
|
||||
sms SMS related comamnds
|
||||
subscriber Operations on a Subscriber
|
||||
----
|
||||
<1> press `?` here at the prompt, the character will not be printed
|
||||
|
||||
If you have already entered a partial comamnd, `?` will help you to
|
||||
review possible options of how to continue your command. Let's say you
|
||||
remember that `show` is used to investigate the system status. But you
|
||||
don't know exactly what the object was called that you'd like to show:
|
||||
You simply press `?` after typing `show` and you will see the following
|
||||
choice:
|
||||
|
||||
.Example: Typing `?` after a partial command
|
||||
----
|
||||
OpenBSC> show <1>
|
||||
version Displays program version
|
||||
online-help Online help
|
||||
history Display the session command history
|
||||
network Display information about a GSM NETWORK
|
||||
bts Display information about a BTS
|
||||
trx Display information about a TRX
|
||||
timeslot Display information about a TS
|
||||
lchan Display information about a logical channel
|
||||
paging Display information about paging reuqests of a BTS
|
||||
paging-group Display the paging group
|
||||
logging Show current logging configuration
|
||||
alarms Show current logging configuration
|
||||
stats Show statistical values
|
||||
e1_driver Display information about available E1 drivers
|
||||
e1_line Display information about a E1 line
|
||||
e1_timeslot Display information about a E1 timeslot
|
||||
subscriber Operations on a Subscriber
|
||||
statistics Display network statistics
|
||||
sms-queue Display SMSqueue statistics
|
||||
smpp SMPP Interface
|
||||
----
|
||||
<1> press `?` after the `show` command, the character will not be printed
|
||||
|
||||
Now you decide you want to have a look at the the `network` object, so
|
||||
you type network and press `?` again:
|
||||
|
||||
.Example: Typing `?` after `show network`
|
||||
----
|
||||
OpenBSC> show network
|
||||
<cr>
|
||||
----
|
||||
|
||||
By presenting `<cr>` as the only option, the VTY tells you that your
|
||||
command is complete and does not support any additional arguments.
|
||||
|
||||
==== TAB completion
|
||||
|
||||
The VTY supports tab (tabulator) completion. Simply type any partial
|
||||
command and press `<tab>`, and it will either show you a choice of
|
||||
possible continuations, or complete the command if there's only one
|
||||
alternative.
|
||||
|
||||
.Example: Use of `<tab>` pressed after typing only `s` as command
|
||||
----
|
||||
OpenBSC> s<1>
|
||||
show sms subscriber
|
||||
----
|
||||
<1> press `<tab>` here.
|
||||
|
||||
At this point you then have to decide how to continue typing your
|
||||
command. Let's assume you choose `show`, and then press `<tab>` again:
|
||||
|
||||
.Example: Use of `<tab>` pressed after typing `show` command
|
||||
----
|
||||
OpenBSC> show <1>
|
||||
version online-help history network bts trx
|
||||
timeslot lchan paging paging-group logging alarms
|
||||
stats e1_driver e1_line e1_timeslot subscriber statistics
|
||||
sms-queue smpp
|
||||
----
|
||||
<1> press `<tab>` here.
|
||||
|
||||
|
||||
==== The `list` command
|
||||
|
||||
The `list` command will give you a full list of all commands available
|
||||
at this node:
|
||||
|
||||
.Example: Typing `list` at start of OsmoNITB 'VIEW' node prompt
|
||||
----
|
||||
OpenBSC> list
|
||||
show version
|
||||
show online-help
|
||||
list
|
||||
exit
|
||||
help
|
||||
enable
|
||||
terminal length <0-512>
|
||||
terminal no length
|
||||
who
|
||||
show history
|
||||
show network
|
||||
show bts [<0-255>]
|
||||
show trx [<0-255>] [<0-255>]
|
||||
show timeslot [<0-255>] [<0-255>] [<0-7>]
|
||||
show lchan [<0-255>] [<0-255>] [<0-7>] [lchan_nr]
|
||||
show lchan summary [<0-255>] [<0-255>] [<0-7>] [lchan_nr]
|
||||
show paging [<0-255>]
|
||||
show paging-group <0-255> IMSI
|
||||
logging enable
|
||||
logging disable
|
||||
logging filter all (0|1)
|
||||
logging color (0|1)
|
||||
logging timestamp (0|1)
|
||||
logging print extended-timestamp (0|1)
|
||||
logging print category (0|1)
|
||||
logging set-log-mask MASK
|
||||
logging level (all|rll|cc|mm|rr|rsl|nm|mncc|pag|meas|sccp|msc|mgcp|ho|db|ref|gprs|ns|bssgp|llc|sndcp|nat|ctrl|smpp|filter|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats) (everything|debug|info|notice|error|fatal)
|
||||
show logging vty
|
||||
show alarms
|
||||
show stats
|
||||
show stats level (global|peer|subscriber)
|
||||
show e1_driver
|
||||
show e1_line [line_nr] [stats]
|
||||
show e1_timeslot [line_nr] [ts_nr]
|
||||
show subscriber (extension|imsi|tmsi|id) ID
|
||||
show subscriber cache
|
||||
sms send pending
|
||||
subscriber create imsi ID
|
||||
subscriber (extension|imsi|tmsi|id) ID sms sender (extension|imsi|tmsi|id) SENDER_ID send .LINE
|
||||
subscriber (extension|imsi|tmsi|id) ID silent-sms sender (extension|imsi|tmsi|id) SENDER_ID send .LINE
|
||||
subscriber (extension|imsi|tmsi|id) ID silent-call start (any|tch/f|tch/any|sdcch)
|
||||
subscriber (extension|imsi|tmsi|id) ID silent-call stop
|
||||
subscriber (extension|imsi|tmsi|id) ID ussd-notify (0|1|2) .TEXT
|
||||
subscriber (extension|imsi|tmsi|id) ID update
|
||||
show statistics
|
||||
show sms-queue
|
||||
logging filter imsi IMSI
|
||||
show smpp esme
|
||||
----
|
||||
|
||||
TIP: Remember, the list of available commands will change significantly
|
||||
depending on the Osmocom program you are accessing, and the current node
|
||||
you're at. Compare the above example of the OsmoNITB 'VIEW' node with
|
||||
the result from the OsmoNITB 'TRX' config node:
|
||||
|
||||
.Example: Typing `list` at start of OsmoNITB 'TRX' config node prompt
|
||||
----
|
||||
OpenBSC(config-net-bts-trx)# list
|
||||
help
|
||||
list
|
||||
write terminal
|
||||
write file
|
||||
write memory
|
||||
write
|
||||
show running-config
|
||||
exit
|
||||
end
|
||||
arfcn <0-1023>
|
||||
description .TEXT
|
||||
no description
|
||||
nominal power <0-100>
|
||||
max_power_red <0-100>
|
||||
rsl e1 line E1_LINE timeslot <1-31> sub-slot (0|1|2|3|full)
|
||||
rsl e1 tei <0-63>
|
||||
rf_locked (0|1)
|
||||
timeslot <0-7>
|
||||
----
|
|
@ -0,0 +1,115 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<chapter>
|
||||
<title>VTY reference</title>
|
||||
|
||||
<para>The Virtual Tele Type (VTY) has the concept of nodes and commands. This
|
||||
chapter lists all nodes and the commands that are available within the node.
|
||||
Each command can consist out of several words followed by a variable number of
|
||||
parameters. There are common patterns for the parameters, these include IPv4
|
||||
addresses, number ranges, a word, a line of text and choice. The following will
|
||||
explain the commonly used patterns.
|
||||
</para>
|
||||
|
||||
<table frame='all' id="table.vty_patterns"><title>VTY Parameter Patterns</title>
|
||||
<tgroup cols='3' align='left' colsep='1' rowsep='1'>
|
||||
<colspec column="1" colname="pattern" colwidth="0.5*" />
|
||||
<colspec column="2" colname="example" colwidth="0.5*" />
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Pattern</entry>
|
||||
<entry>Example</entry>
|
||||
<entry>Explanation</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>A.B.C.D</entry>
|
||||
<entry>127.0.0.1</entry>
|
||||
<entry>A IPv4 address</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>TEXT</entry>
|
||||
<entry>example01</entry>
|
||||
<entry>A single string without any spaces, tabs</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>.TEXT</entry>
|
||||
<entry>Some information</entry>
|
||||
<entry>A line of text</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>(OptionA|OptionB|OptionC)</entry>
|
||||
<entry>OptionA</entry>
|
||||
<entry>A choice between a list of available options</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><0-10></entry>
|
||||
<entry>5</entry>
|
||||
<entry>A number from a range</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>
|
||||
The application is configured through the VTY. For configuring a system
|
||||
one needs to enter the <command>enable</command> node and then enter the
|
||||
<command>configure terminal</command> command. Then the configuration can be
|
||||
made according to the available commands. After the system has been configured
|
||||
one can use the <command>write</command> command to write the new configuration
|
||||
to the configuration file. The new file will be used after the application
|
||||
has been restarted.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
The following table lists the TCP port numbers of the VTY for the
|
||||
various Osmocom GSM related programs as used on sysmocom products:
|
||||
</para>
|
||||
|
||||
<table frame="all" id="table.vty_port"><title>VTY port numbers</title>
|
||||
<tgroup cols='2' align='left' colsep='1' rowsep='1'>
|
||||
<colspec column="1" colname="port_number" colwidth="0.5*" />
|
||||
<colspec column="2" colname="software" colwidth="0.5*" />
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Port Number</entry>
|
||||
<entry>Software</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>4240</entry>
|
||||
<entry>osmo-pcu</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>4241</entry>
|
||||
<entry>osmo-bts</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>4242</entry>
|
||||
<entry>osmo-nitb, osmo-bsc</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>4243</entry>
|
||||
<entry>osmo-bsc_mgcp</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>4244</entry>
|
||||
<entry>osmo-bsc_nat</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>4245</entry>
|
||||
<entry>osmo-sgsn</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>4246</entry>
|
||||
<entry>osmo-gbproxy</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
§ions-vty;
|
||||
</chapter>
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue