From cec90c77924e749911ccba6abdd0e4a32b9904e1 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Tue, 25 Apr 2017 15:06:40 +0200 Subject: osmocon slides update --- 2017/bts_hardware-osmocon2017/bts_hardware.html | 4270 +++++ .../running-foss-gsm.adoc | 2 +- .../path_loss_link_budget.html | 5039 ++++++ 2017/roadmap-osmocon2017/roadmap.html | 4448 ++++++ .../Gsm_structures.svg | 15874 +++++++++++++++++++ .../arch-sysmobts-allinone.dot | 27 + .../running_osmo_gsm-osmocon2017/arch-sysmobts.dot | 30 + .../arch-usrp-allinone.dot | 30 + 2017/running_osmo_gsm-osmocon2017/arch-usrp.dot | 31 + .../gprs_user_stack.svg | 1357 ++ 2017/running_osmo_gsm-osmocon2017/osmo-bts.svg | 342 + 2017/running_osmo_gsm-osmocon2017/osmocom-gprs.svg | 1191 ++ 2017/running_osmo_gsm-osmocon2017/osmocom-gsm.svg | 1980 +++ .../running-osmo-gsm.adoc | 495 + .../running-osmo-gsm.html | 5018 ++++++ 2017/welcome_intro-osmocon2017/welcome_intro.adoc | 8 +- 2017/welcome_intro-osmocon2017/welcome_intro.html | 4205 +++++ 17 files changed, 44344 insertions(+), 3 deletions(-) create mode 100644 2017/bts_hardware-osmocon2017/bts_hardware.html create mode 100644 2017/path_loss_link_budget-osmocon2017/path_loss_link_budget.html create mode 100644 2017/roadmap-osmocon2017/roadmap.html create mode 100644 2017/running_osmo_gsm-osmocon2017/Gsm_structures.svg create mode 100644 2017/running_osmo_gsm-osmocon2017/arch-sysmobts-allinone.dot create mode 100644 2017/running_osmo_gsm-osmocon2017/arch-sysmobts.dot create mode 100644 2017/running_osmo_gsm-osmocon2017/arch-usrp-allinone.dot create mode 100644 2017/running_osmo_gsm-osmocon2017/arch-usrp.dot create mode 100644 2017/running_osmo_gsm-osmocon2017/gprs_user_stack.svg create mode 100644 2017/running_osmo_gsm-osmocon2017/osmo-bts.svg create mode 100644 2017/running_osmo_gsm-osmocon2017/osmocom-gprs.svg create mode 100644 2017/running_osmo_gsm-osmocon2017/osmocom-gsm.svg create mode 100644 2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.adoc create mode 100644 2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.html create mode 100644 2017/welcome_intro-osmocon2017/welcome_intro.html diff --git a/2017/bts_hardware-osmocon2017/bts_hardware.html b/2017/bts_hardware-osmocon2017/bts_hardware.html new file mode 100644 index 0000000..5f0643f --- /dev/null +++ b/2017/bts_hardware-osmocon2017/bts_hardware.html @@ -0,0 +1,4270 @@ + + + + +Osmocom BTS Hardware Support + + + + + + + + +

Overview

Clasic E1/T1 based BTS

Supported Vendors/Dialects

+ +Siemens (only BS-11 tested) + +
+ +Ericsson RBS2xxx (RBS2307, 2308, 2111 tested) + +
+ +Nokia InSite, MetroSite + +

+ +++ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Pro	Con
available inexpensively from decomissioned sites	appears a bit antiquated
up to 12 TRX	not many people familiar with E1/T1 anymore
high RF output power	no convenient testing/debugging of E1/T1 issues
rugged mechanical build, high MTTF	high power consumption
	older models no EGPRS, no AMR

Classic E1/T1 based BTS

Clasic E1/T1 based BTS

+ +This is how it all started + +
+ +E1 based BTS (Siemens BS-11) + +
+ +HAR 2009 - Dutch Hacker Camp + +
+ +Antennas mounted with duct tape to tree + +
+ +E1 back-haul over CAT5 to OpenBSC running in tent + +

Ericsson RBS 2308

+ +Many RBS2000 models + +
+ +All very similar on protocol + +
+ +Not all models tested + +
+ +Good results with RBS2308 + RBS2111 + +

ip.access nanoBTS

+ +PoE-enabled single-TRX 200mW indoor BTS + +
+ +GPRS/GSM only models and EGPRS-enabled models + +
+ +available in band-specific versions for all four bands + +
+ +proprietary BTS and PCU inside + +
- + +lots of PCU crashes reported by users :( + +
- + +no way for us to fix it + +
+
+ +No fully dynamic channels (TCH/F + TCH/H + PDCH) + +

sysmoBTS

+ +sysmocom builds family of GSM BTS based on OsmoBTS + OsmoPCU + +
+ +revenue from this sales used to cross-subsidize OsmoBTS development + +
+ +osmo-bts-sysmo uses shared-memory /dev to talk to PHY + +
+ +osmo-pcu uses shared-memory /dev to talk to PHY + +

+ +++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Model	RF Pwr	TRX	Outdoor	PoE	Quad-Band
sysmoBTS 1002	0.2 W	1	No	No	Yes
sysmoBTS 1002 OD	0.2 W	1	Yes	Yes	Yes
sysmoBTS 1020	2.0 W	1	Yes	Yes	No
sysmoBTS 1100	10.0 W	1	Yes	No	No
sysmoBTS 2050	2x 5 W	2	Yes	No	No
sysmoBTS 2100	2x10 W	2	Yes	No	No

Nuran LiteCell 1.5

+ +10W 2-TRX Outdoor BTS + +
+ +osmo-bts-litecell15 uses shared-memory /dev to talk to PHY + +
+ +osmo-pcu uses shared-memory /dev to talk to PHY + +

Octasic OCTBTS with OCTPHY-2G

+ +not a ready-to-deploy BTS product, more a BTS development board + +
- + +no enclosure, no PA, no filters + +
+
+ +proprietary PHY runs in Octasic DSP + +
- + +raw Ethernet frames towards osmo-bts-octphy + +
- + +unix domain pcu-socket to osmo-pcu + +
+
+ +series of different board models (3000, 3500, 3600) with different + number of DSPs, radio interfaces, ARM/x86 processor core + +
+ +two TRX per DSP possible + +
+ +not all voice codecs supported + +
+ +EGRPS integration with OsmoPCU not working yet + +

EOF

End of File

+ + diff --git a/2017/open_source_mobilfunk-clt2017/running-foss-gsm.adoc b/2017/open_source_mobilfunk-clt2017/running-foss-gsm.adoc index 45ce701..47db6ae 100644 --- a/2017/open_source_mobilfunk-clt2017/running-foss-gsm.adoc +++ b/2017/open_source_mobilfunk-clt2017/running-foss-gsm.adoc @@ -698,4 +698,4 @@ LTE cells, similar to 3.5G strategy * the entire Osmocom team for what they have achieved ** notably Dieter Spaar, Holger Freyther, Andreas Eversberg, Sylvain Munaut * last but not least: CEPT for making the GSM specs English -** (who'd want to read French specs anyway?) +** (who'd want to read French specs here?) diff --git a/2017/path_loss_link_budget-osmocon2017/path_loss_link_budget.html b/2017/path_loss_link_budget-osmocon2017/path_loss_link_budget.html new file mode 100644 index 0000000..bce64b7 --- /dev/null +++ b/2017/path_loss_link_budget-osmocon2017/path_loss_link_budget.html @@ -0,0 +1,5039 @@ + + + + +Path Loss and Link Budget + + + + + + + + +

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.

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.

Radio Propagation Models

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:

Common Path Loss Models

+ + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 1. List of common path loss models
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.

RF Power in a Wireless Link

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

Simplified Link Budget Equation

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

Link Budget Equation vs. Path Loss

+ +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. + +
+
+NOTE +
+
+
+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. +
+
+
+

RF Link

Uplink Link Budget

The transmit power of a MS depends on various factors, such as the MS +Power Class, the frequency band and the modulation scheme used.

+ + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 2. 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

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

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.

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

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

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.

Figure 1. Illustration of the Duplexer functionality

+ + + +

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

Figure 2. Addition of a RF Power Amplifier to a GSM BTS Setup

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

Figure 3. Addition of a RF Low Noise Amplifier to the GSM BTS Setup

Figure 4. Addition of a RF LNA + RF PA to the GSM BTS Setup

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.

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.

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.

+ + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 3. 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

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:

+ + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 4. 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

The End

Questions?

+ + diff --git a/2017/roadmap-osmocon2017/roadmap.html b/2017/roadmap-osmocon2017/roadmap.html new file mode 100644 index 0000000..c1950f6 --- /dev/null +++ b/2017/roadmap-osmocon2017/roadmap.html @@ -0,0 +1,4448 @@ + + + + +Osmocom Callular Infrastructure Roadmap + + + + + + + + +

Disclaimer

People like Dieter, Holger, Daniel and I have invested lots of our +spare time in the early years. So funding for that came from other +paid work, and Osmocom projects were a hobby. It was a lot of fun, but +it’s not a sustainable basis for the scope of the projects at this +time.

Today, our development is driven by

+ +what people contribute patches for, and/or + +
+ +what companies and consultants in the project get development + contracts for (e.g. sysmocom customers) + +

This means in general that very little will happen, unless somebody +commits to putting resources at it!

Major Roadmap Areas

+ +Splitting up the NITB + +
+ +Code Quality + +
+ +Testing + +
+ +Integration between 2G and 3G + +
+ +External Interfaces + +

OsmoNITB

+ +has been at the heart of most Osmocom based cellular networks + +
+ +is generally doing a good job, but suffers from some issues + +
+ +NITB includes BSC, but BSC code also used to build OsmoBSC + +
- + +No way to test OsmoBSC without a proprietary MSC :( + +
+
+ +NITB includes sqlite3 based HLR + +
- + +synchronous/blocking access from single-threaded OsmoNITB + +
- + +sqlite3 (particularly via DBI) scalability issues + +
+

RIP NITB; Long Live OsmoMSC

+ +New OsmoMSC = OsmoNITB - BSC - HLR + +
+ +New OsmoHLR (GSUP interface only) + +
+ +3GPP A-over-IP for OsmoBSC + OsmoMSC + +
- + +New SCCP+M3UA stack, libosmo-sigtran + +
+
+ +M3UA based IuCS/IuPS in HNB-GW, MSC, SGSN + +
- + +used to be SUA, as it was simpler initially + +
+
+ +Single code base/branch for 2G and 3G + +

→ typical 2G setup will become OsmoBSC + OsmoMSC + OsmoHLR

OsmoSTP

Signal Transfer Point, part of libosmo-sccp

+ +M3UA + SUA support + +
+ +Connectionless and Conenction Oriented SCCP + +
+ +Used primarily for RAN-CN interface (A, Iu) so far + +

osmo_fsm + osmo_prim

+osmo_fsm +: +
+structured approach to state machines +
+
+osmo_prim +: +
+structured approach towards primitives at SAP between layers +
+

osmo_fsm

Generalized finite state machine (FSM) abstraction

+ +pure C language, no pre-processor / code-generator + +
+ +description of states, permitted events in a state, permitted + output states + +
+ +buit-in timer support. Default action on expiry: Destroy FSM + +
+ +parent/children relationship, allows hierarchy of FSMs + +

Much more maintainable and deterministic than the many implicit or +non-existing state machines in older code

osmo_fsm so far

+ +Ericsson OM2000 managed objects + +
+ +Connection-Oriented SCCP + +
+ +M3UA/SUA ASP + AS state machine + +
+ +All VLR FSMs (LU, Auth, …) in OsmoMSC + +
+ +AMR DTX in OsmoBTS + +

osmo_fsm candidates

+ +LAPD + LAPDm code + +
+ +A-bis OML managed objects + +
+ +GSM Call Control (maybe even CAMEL-like FSMs?) + +

More osmo_fsm Would greatly improve code quality, testability and +maintainability

+ +but who wants to invest in that? Any volunteers? + +

Testing

+ +unit test coverage of most code is poor, needs attention + +
- + +coverage of new code much better than old code + +
+
+ +osmo_fsm state introspection via CTRL enables better testing + +
+ +end-to-end system testing software: osmo-gsm-tester + +

osmo-gsm-tester

+ +python language for managing BTSs + Modems + +
- + +supports different BTS models + +
- + +can execute suites of test cases on each software version for all BTS models + +
+
+ +RF cabling between BTSs and Modems to avoid RF interference + +

→ GOAL: Daily functional testing on all supported platforms/configs

osmo-gsm-tester

+ +core python infrastructure working + +
+ +jenkins integration for testing new builds working + +
+ +modem hardware being replaced due to poor ofono support for SL8082 + +

TODO:

+ +modem integration using better supported hardware + +
+ +more actual test cases beyond SMS + LU + +
+ +3G support + +

External Interfaces

+ +VTY is a human interface, not intended for consumption by software + +
- + +text output syntax not guaranteed stable + +
- + +inefficient + +
- + +commands get added during development to help developers + +
+
+ +CTRL interface is the programmatic interface + +
- + +but developers don’t need it during development + +
- + +all commands so far added due to user request/requirement + +
  - + +let us know what you need exposed! + +
  +
- + +only way to fundamentally change this is to automatically export things without extra effort + +
+

⇒ Roadmap is to put more effort into CTRL completeness

Grand Unified Config Theory

Big Wishlist item:

+ +Unified configuration store / MIB with + +
- + +automatic VTY printer/parser generation + +
- + +automatic CTRL interface exposure + +
- + +telnet/VTY process + MIB daemon outside actual applications + +
+

But who will fund this / put resources at it?

Integration between 2G and 3G

+ +so far, 2G and 3G live separate to each other + +
+ +we want integration + +
- + +cross-advertisement of neighbor cells + +
- + +inter-RAT mobility + +
- + +inter-RAT hand-over + +
+
+ +combined PS + CS attach + +
+ +SMS over packet switched + +

Operation / Maintenance

+ +generation of Alarms in BTS + PCU (done) + +
+ +report via CTRL TRAP as well as A-bis OML (done) + +
+ +centralized reporting / collections of Alarms (tbd) + +

→ we need to generate more alarms in abnormal situations

+ +generation of more stat, counters / KPIs + +
- + +lots of work spent in 2016 on this alrady + +
+

→ we need aggregation/interpretation/analysis of that data

Further Wishlist

+ +move SMSC out of OsmoMSC + +
+ +GSUP to MAP gateway + +
+ +billing interfaces + +
+ +LTE MME/S-GW-/P-GW + +
- + +biggest issue is lack of good FOSS asn.1 tools for C + +
- + +we either have to ditch C, or invest lots of time in tools :/ + +
+

EOF

End of File

+ + diff --git a/2017/running_osmo_gsm-osmocon2017/Gsm_structures.svg b/2017/running_osmo_gsm-osmocon2017/Gsm_structures.svg new file mode 100644 index 0000000..cd68155 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/Gsm_structures.svg @@ -0,0 +1,15874 @@ + + + + diff --git a/2017/running_osmo_gsm-osmocon2017/arch-sysmobts-allinone.dot b/2017/running_osmo_gsm-osmocon2017/arch-sysmobts-allinone.dot new file mode 100644 index 0000000..2efbfd5 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/arch-sysmobts-allinone.dot @@ -0,0 +1,27 @@ +graph G { + rankdir=LR; + MS0 [label="MS",shape=box] + MS1 [label="MS",shape=box] + MS2 [label="MS",shape=box] + + MS0--PHY [label="Um"] + MS1--PHY [label="Um"] + MS2--PHY [label="Um"] + + subgraph cluster_0 { + label = "sysmoBTS (all-in-one)" + OsmoBTS + OsmoPCU [style="dashed"] + PHY -- OsmoBTS [label="shmem msgq"] + PHY -- OsmoPCU [label="shmem msgq"] + OsmoPCU -- OsmoBTS [label="pcu_sock"] + { rank=same; OsmoBTS OsmoPCU } + + OsmoNITB + OsmoSGSN [style="dashed"] + OsmoBTS -- OsmoNITB [label="Abis/IP\n(lo)"] + OsmoPCU -- OsmoSGSN [label="Gb/IP\n(lo)"] + + { rank=same; OsmoNITB OsmoSGSN } + } +} diff --git a/2017/running_osmo_gsm-osmocon2017/arch-sysmobts.dot b/2017/running_osmo_gsm-osmocon2017/arch-sysmobts.dot new file mode 100644 index 0000000..9375fc9 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/arch-sysmobts.dot @@ -0,0 +1,30 @@ +graph G { + rankdir=LR; + MS0 [label="MS",shape=box] + MS1 [label="MS",shape=box] + MS2 [label="MS",shape=box] + + MS0--PHY [label="Um"] + MS1--PHY [label="Um"] + MS2--PHY [label="Um"] + + subgraph cluster_0 { + label = "sysmoBTS" + OsmoBTS + OsmoPCU [style="dashed"] + PHY -- OsmoBTS [label="shmem msgq"] + PHY -- OsmoPCU [label="shmem msgq"] + OsmoPCU -- OsmoBTS [label="pcu_sock"] + { rank=same; OsmoBTS OsmoPCU } + } + + subgraph cluster_1 { + label = "Linux PC" + OsmoNITB + OsmoSGSN [style="dashed"] + OsmoBTS -- OsmoNITB [label="Abis/IP"] + OsmoPCU -- OsmoSGSN [label="Gb/IP"] + + { rank=same; OsmoNITB OsmoSGSN } + } +} diff --git a/2017/running_osmo_gsm-osmocon2017/arch-usrp-allinone.dot b/2017/running_osmo_gsm-osmocon2017/arch-usrp-allinone.dot new file mode 100644 index 0000000..11ab81e --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/arch-usrp-allinone.dot @@ -0,0 +1,30 @@ +graph G { + rankdir=LR; + MS0 [label="MS",shape=box] + MS1 [label="MS",shape=box] + MS2 [label="MS",shape=box] + + USRP [label="USRP Bxxx",shape=box] + USRP -- OsmoTRX [label="USB"] + + MS0--USRP [label="Um"] + MS1--USRP [label="Um"] + MS2--USRP [label="Um"] + + subgraph cluster_0 { + label = "Linux PC (all-in-one)" + OsmoTRX + OsmoBTS + OsmoPCU [style="dashed"] + OsmoPCU -- OsmoBTS [label="pcu_sock"] + OsmoTRX -- OsmoBTS [label="UDP"] + { rank=same; OsmoBTS OsmoPCU } + + OsmoNITB + OsmoSGSN [style="dashed"] + OsmoBTS -- OsmoNITB [label="Abis/IP\n(lo)"] + OsmoPCU -- OsmoSGSN [label="Gb/IP\n(lo)"] + + { rank=same; OsmoNITB OsmoSGSN } + } +} diff --git a/2017/running_osmo_gsm-osmocon2017/arch-usrp.dot b/2017/running_osmo_gsm-osmocon2017/arch-usrp.dot new file mode 100644 index 0000000..9426c08 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/arch-usrp.dot @@ -0,0 +1,31 @@ +graph G { + rankdir=LR; + MS0 [label="MS",shape=box] + MS1 [label="MS",shape=box] + MS2 [label="MS",shape=box] + + USRP [label="USRP Bxxx",shape=box] + USRP --OsmoTRX [label="USB"] + + MS0--USRP [label="Um"] + MS1--USRP [label="Um"] + MS2--USRP [label="Um"] + + subgraph cluster_0 { + label = "Linux PC (BTS)" + OsmoTRX + OsmoBTS + OsmoPCU [style="dashed"] + OsmoPCU -- OsmoBTS [label="pcu_sock"] + OsmoTRX -- OsmoBTS + { rank=same; OsmoBTS OsmoPCU } + } + + subgraph cluster_1 { + label = "Linux PC (Core)" + OsmoNITB + OsmoSGSN [style="dashed"] + OsmoBTS -- OsmoNITB [label="Abis/IP"] + OsmoPCU -- OsmoSGSN [label="Gb/IP"] + } +} diff --git a/2017/running_osmo_gsm-osmocon2017/gprs_user_stack.svg b/2017/running_osmo_gsm-osmocon2017/gprs_user_stack.svg new file mode 100644 index 0000000..6b702a2 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/gprs_user_stack.svg @@ -0,0 +1,1357 @@ + + + + diff --git a/2017/running_osmo_gsm-osmocon2017/osmo-bts.svg b/2017/running_osmo_gsm-osmocon2017/osmo-bts.svg new file mode 100644 index 0000000..5f24c35 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/osmo-bts.svg @@ -0,0 +1,342 @@ + + + + diff --git a/2017/running_osmo_gsm-osmocon2017/osmocom-gprs.svg b/2017/running_osmo_gsm-osmocon2017/osmocom-gprs.svg new file mode 100644 index 0000000..0506053 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/osmocom-gprs.svg @@ -0,0 +1,1191 @@ + + + + diff --git a/2017/running_osmo_gsm-osmocon2017/osmocom-gsm.svg b/2017/running_osmo_gsm-osmocon2017/osmocom-gsm.svg new file mode 100644 index 0000000..8f2ac6d --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/osmocom-gsm.svg @@ -0,0 +1,1980 @@ + + + + diff --git a/2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.adoc b/2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.adoc new file mode 100644 index 0000000..1f87a65 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.adoc @@ -0,0 +1,495 @@ +Running a basic Osmocom GSM network +=================================== +:author: Harald Welte +:copyright: sysmocom - s.f.m.c. GmbH (License: CC-BY-SA) +:backend: slidy +:max-width: 45em +//:data-uri: +//:icons: + + +== What this talk is about + +[role="incremental"] +* Implementing GSM/GPRS network elements as FOSS +* Applied Protocol Archaeology +* Doing all of that on top of Linux (in userspace) + + +== Running your own Internet-style network + +* use off-the-shelf hardware (x86, Ethernet card) +* use any random Linux distribution +* configure Linux kernel TCP/IP network stack +** enjoy fancy features like netfilter/iproute2/tc +* use apache/lighttpd/nginx on the server +* use Firefox/chromium/konqueor/lynx on the client +* do whatever modification/optimization on any part of the stack + + +== Running your own GSM network + +Until 2009 the situation looked like this: + +* go to Ericsson/Huawei/ZTE/Nokia/Alcatel/... +* spend lots of time convincing them that you're an eligible customer +* spend a six-digit figure for even the most basic full network +* end up with black boxes you can neither study nor improve + +[role="incremental"] +- WTF? +- I've grown up with FOSS and the Internet. I know a better world. + + +== Why no cellular FOSS? + +- both cellular (2G/3G/4G) and TCP/IP/HTTP protocol specs are publicly + available for decades. Can you believe it? +- Internet protocol stacks have lots of FOSS implementations +- cellular protocol stacks have no FOSS implementations for the + first almost 20 years of their existence? +[role="incremental"] +- it's the classic conflict + * classic circuit-switched telco vs. the BBS community + * ITU-T/OSI/ISO vs. Arpanet and TCP/IP + + +== Enter Osmocom + +In 2008, some people (most present in this room) started to write FOSS +for GSM + +- to boldly go where no FOSS hacker has gone before +[role="incremental"] +** where protocol stacks are deep +** and acronyms are plentiful +** we went from `bs11-abis` to `bsc_hack` to 'OpenBSC' +** many other related projects were created +** finally leading to the 'Osmocom' umbrella project + + +== Classic GSM network architecture + +image::Gsm_structures.svg[width=850] + + +== GSM Acronyms, Radio Access Network + +MS:: + Mobile Station (your phone) +BTS:: + Base Transceiver Station, consists of 1..n TRX +TRX:: + Transceiver for one radio channel, serves 8 TS +TS:: + Timeslots in the GSM radio interface; each runs a specific combination of logical channels +BSC:: + Base Station Controller + + +== GSM Acronyms, Core Network + +MSC:: + Mobile Switching Center; Terminates MM + CC Sub-layers + +HLR:: + Home Location Register; Subscriber Database + +SMSC:: + SMS Service Center + + +== GSM Acronyms, Layer 2 + 3 + +LAPDm:: + Link Access Protocol, D-Channel. Like LAPD in ISDN +RR:: + Radio Resource (establish/release dedicated channels) +MM:: + Mobility Management (registration, location, authentication) +CC:: + Call Control (voice, circuit switched data, fax) +CM:: + Connection Management + + +== Osmocom GSM components + +image::osmocom-gsm.svg[width=850] + + +== Classic GSM network as digraph + +[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 +} +---- + +== Simplified OsmoNITB GSM network + +[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; + } +} +---- + +which further reduces to the following minimal setup: + +[graphviz] +---- +digraph G { + rankdir=LR; + MS0 [label="MS"] + BTS0 [label="BTS"] + MS0->BTS0 [label="Um"] + BTS0->BSC [label="Abis"] + BSC [label="OsmoNITB"]; +} +---- + +So our minimal setup is a 'Phone', a 'BTS' and 'OsmoNITB'. + +== Which BTS to use? + +* Proprietary BTS of classic vendor +** Siemens BS-11 is what we started with +** Nokia, Ericsson, and others available 2nd hand +* 'OsmoBTS' software implementation, running with +** Proprietary HW + PHY (DSP): 'sysmoBTS', or +** General purpose SDR (like USRP) + 'OsmoTRX' + +We assume a sysmoBTS in the following tutorial + + +== OsmoBTS Overview + +image::osmo-bts.svg[] + +* Implementation of GSM BTS +* supports variety of hardware/PHY options +** `osmo-bts-sysmo`: BTS family by sysmocom +** `osmo-bts-trx`: Used with 'OsmoTRX' + general-purpose SDR +** `osmo-bts-octphy`: Octasic OCTBTS hardware / OCTSDR-2G PHY +** `osmo-bts-litecell15`: Nutaq Litecell 1.5 hardware/PHY + +See separate talk about BTS hardware options later today. + +== BTS Hardware vs. BTS software + +* A classic GSM BTS is hardware + software +* It has two interfaces +** Um to the radio side, towards phones +** Abis to the wired back-haul side, towards BSC +* with today's flexible architecture, this is not always true +** the hardware might just be a network-connected SDR and BTS software +runs o a different CPU/computer, _or_ +** the BTS and BSC, or even the NITB may run on the same board + + +== Physical vs. Logical Arch (sysmoBTS) + +[graphviz] +---- +include::arch-sysmobts.dot[] +---- + +[graphviz] +---- +include::arch-sysmobts-allinone.dot[] +---- + +== Physical vs. Logical Arch (SDR e.g. USRP B2xx) + +[graphviz] +---- +include::arch-usrp.dot[] +---- + +[graphviz] +---- +include::arch-usrp-allinone.dot[] +---- + +== IP layer traffic + +* Abis/IP signaling runs inside IPA multiplex inside TCP +** Port 3002 and 3003 betewen BTS and BSC +** Connections initiated from BTS to BSC +* Voice data is carried in RTP/UDP on dynamic ports + +=> Make sure you permit the above communication in your +network/firewall config + +== Configuring Osmocom software + +* all _native_ Osmo* GSM infrastructure programs share common architecture, as + defined by various libraries 'libosmo{core,gsm,vty,abis,netif,...}' +* part of this is configuration handling +** interactive configuration via command line interface (*vty*), similar + to Cisco routers +** based on a fork of the VTY code from Zebra/Quagga, now 'libosmovty' +* you can manually edit the config file, +* or use `configure terminal` and interactively change it + + +== Configuring OsmoBTS + +* 'OsmoBTS' in our example scenario runs on the embedded ARM/Linux system + inside the 'sysmoBTS' +* we access the 'sysmoBTS' via serial console or ssh +* we then edit the configuration file `/etc/osmocom/osmo-bts.cfg` as + described in the following slide + + +== Configuring OsmoBTS + +---- +bts 0 + band DCS1800 <1> + ipa unit-id 1801 0 <2> + oml remote-ip 192.168.100.11 <3> +---- +<1> the GSM frequency band in which the BTS operates +<2> the unit-id by which this BTS identifies itself to the BSC +<3> the IP address of the BSC (to establish the OML connection towards it) + +NOTE: All other configuration is downloaded by the BSC via OML. So most +BTS settings are configured in the BSC/NITB configuration file. + + +== Purpose of Unit ID + +* Unit IDs consist of three parts: +** Site Number, BTS Number, TRX Number + +[graphviz] +---- +graph G { + rankdir=LR; + BTS0 [label="BTS\nUnit 5/0[/0]"] + BTS1 [label="BTS\nUnit 23/0[/0]"] + BTS2 [label="BTS\nUnit 42/0[/0]"] + NAT + BSC [label="BSC/NITB"] + + BTS0 -- NAT [label="10.9.23.5"] + BTS1 -- NAT [label="10.9.23.23"] + BTS2 -- NAT [label="10.9.23.42"] + NAT -- BSC [label="172.16.23.42"] +} +---- + +* source IP of all BTSs would be identical + +=> BSC identifies BTS on Unit ID, not on Source IP! + + +== Configuring OsmoNITB + +* 'OsmoNITB' is the `osmo-nitb` executable built from the `openbsc` + source tree / git repository +** just your usual `git clone && autoreconf -fi && ./configure && make install` +** (in reality, the `libosmo*` dependencies are required first...) +** nightly packages for Debian 8, Ubuntu 16.04 and 16.10 available +* 'OsmoNITB' runs on any Linux system, like your speakers' laptop +** you can actually also run it on the ARM/Linux of the 'sysmoBTS' itself, + having a literal 'Network In The Box' with power as only external + dependency + + +== Configuring OsmoNITB + +---- +network + network country code 1 <1> + mobile network code 1 <2> + short name Osmocom <3> + long name Osmocom + auth policy closed <4> + encryption a5 0 <5> +---- +<1> MCC (Country Code) e.g. 262 for Germany; 1 == Test +<2> MNC (Network Code) e.g. mcc=262, mnc=02 == Vodafone; 1 == Test +<3> Operator name to be sent to the phone *after* registration +<4> Only accept subscribers (SIM cards) explicitly authorized in HLR +<5> Use A5/0 (== no encryption) + + +== Configuring BTS in OsmoNITB (BTS) + +---- +network + bts 0 + type sysmobts <1> + band DCS1800 <2> + ms max power 33 <3> + periodic location update 6 <4> + ip.access unit_id 1801 0 <5> + codec-support fr hr efr amr <6> +---- +<1> type of the BTS that we use (must match BTS) +<2> frequency band of the BTS (must match BTS) +<3> maximum transmit power phones are permitted (33 dBm == 2W) +<4> interval at which phones should send periodic location update (6 minutes) +<5> Unit ID of the BTS (must match BTS) +<6> Voice codecs supported by the BTS + + +== Configuring BTS in OsmoNITB (TRX) + +---- +network + bts 0 + trx 0 + arfcn 871 <1> + max_power_red 0 <2> + timeslot 0 + phys_chan_config CCCH+SDCCH4 <3> + timeslot 1 + phys_chan_config TCH/F <4> + ... + timeslot 7 + phys_chan_config PDCH <5> +---- +<1> The RF channel number used by this TRX +<2> The maximum power *reduction* in dBm. 0 = no reduction +<3> Every BTS needs need one timeslot with a CCCH +<4> We configure TS1 to TS6 as TCH/F for voice +<5> We configure TS6 as PDCH for GPRS + + +== What a GSM phone does after power-up + +* Check SIM card for last cell before switch-off +** if that cell is found again, use that +** if not, perform a network scan +*** try to find strong carriers, check if they contain BCCH +*** create a list of available cells + networks +*** if one of the networks MCC+MNC matches first digits of 'IMSI', this is +the home network, which has preference over others +* perform 'LOCATION UPDATE' (TYPE=IMSI ATTACH) procedure to network +* when network sends 'LOCATION UPDATE ACCEPT', *camp* on that cell + +-> let's check if we can perform 'LOCATION UPDATE' on our own network + + +== Verifying our network + +* look at stderr of 'OsmoBTS' and 'OsmoNITB' +** 'OsmoBTS' will terminate if Abis cannot be set-up +** expected to be re-spawned by init / systemd +* use MS to search for networks, try manual registration +* observe registration attempts `logging level mm info` + +-> should show 'LOCATION UPDATE' request / reject / accept + +* use the VTY to explore system state (`show *`) +* use the VTY to change subscriber parameters like extension number + + +== Exploring your GSM networks services + +* use `*#100#` from any registered MS to obtain own number +* voice calls from mobile to mobile +* SMS from mobile to mobile +* SMS to/from external applications (via SMPP) +* voice to/from external PBX (via MNCC) +* explore the VTY interfaces of all network elements +** send SMS from the command line +** experiment with 'silent call' feature +** experiment with logging levels +* use wireshark to investigate GSM protocols + + +== Using the VTY + +* The VTY can be used not only to configure, but also to interactively + explore the system status (`show` commands) +* Every Osmo* program has its own telnet port +|=== +|Program|Telnet Port +|OsmoPCU|4240 +|OsmoBTS|4241 +|OsmoNITB|4242 +|OsmoSGSN|4245 +|=== +* ports are bound to 127.0.0.1 by default +* try tab-completion, `?` and `list` commands + +== Using the VTY (continued) + +* e.g. `show subsciber` to display data about subscriber: +---- +OpenBSC> show subscriber imsi 901700000003804 + ID: 12, Authorized: 1 + Extension: 3804 + LAC: 0/0x0 + IMSI: 901700000003804 + TMSI: F2D4FA0A + Expiration Time: Mon, 07 Dec 2015 09:45:16 +0100 + Paging: not paging Requests: 0 + Use count: 1 +---- + +* try `show bts`, `show trx`, `show lchan`, `show statistics`, ... + +== Further Reading + +User Manuals:: +See http://ftp.osmocom.org/docs/latest/ +Wiki:: +See http://osmocom.org/projects/openbsc + +== The End + +* so long, and thanks for all the fish +* I hope you have questions! + +[role="incremental"] +* have fun exploring mobile technologies using Osmocom +* interested in working with more acronyms? Come join the project! + +* Check out https://osmocom.org/ and openbsc@lists.osmocom.org diff --git a/2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.html b/2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.html new file mode 100644 index 0000000..c162c20 --- /dev/null +++ b/2017/running_osmo_gsm-osmocon2017/running-osmo-gsm.html @@ -0,0 +1,5018 @@ + + + + +Running a basic Osmocom GSM network + + + + + + + + +

What this talk is about

+ +Implementing GSM/GPRS network elements as FOSS + +
+ +Applied Protocol Archaeology + +
+ +Doing all of that on top of Linux (in userspace) + +

Running your own Internet-style network

+ +use off-the-shelf hardware (x86, Ethernet card) + +
+ +use any random Linux distribution + +
+ +configure Linux kernel TCP/IP network stack + +
- + +enjoy fancy features like netfilter/iproute2/tc + +
+
+ +use apache/lighttpd/nginx on the server + +
+ +use Firefox/chromium/konqueor/lynx on the client + +
+ +do whatever modification/optimization on any part of the stack + +

Running your own GSM network

Until 2009 the situation looked like this:

+ +go to Ericsson/Huawei/ZTE/Nokia/Alcatel/… + +
+ +spend lots of time convincing them that you’re an eligible customer + +
+ +spend a six-digit figure for even the most basic full network + +
+ +end up with black boxes you can neither study nor improve + +
- + +WTF? + +
- + +I’ve grown up with FOSS and the Internet. I know a better world. + +
+

Why no cellular FOSS?

+ +both cellular (2G/3G/4G) and TCP/IP/HTTP protocol specs are publicly + available for decades. Can you believe it? + +
+ +Internet protocol stacks have lots of FOSS implementations + +
+ +cellular protocol stacks have no FOSS implementations for the + first almost 20 years of their existence? + +
+ +it’s the classic conflict + +
- + +classic circuit-switched telco vs. the BBS community + +
- + +ITU-T/OSI/ISO vs. Arpanet and TCP/IP + +
+

Enter Osmocom

In 2008, some people (most present in this room) started to write FOSS +for GSM

+ +to boldly go where no FOSS hacker has gone before + +
- + +where protocol stacks are deep + +
- + +and acronyms are plentiful + +
- + +we went from bs11-abis to bsc_hack to OpenBSC + +
- + +many other related projects were created + +
- + +finally leading to the Osmocom umbrella project + +
+

Classic GSM network architecture

GSM Acronyms, Radio Access Network

+MS +: +
+ Mobile Station (your phone) +
+
+BTS +: +
+ Base Transceiver Station, consists of 1..n TRX +
+
+TRX +: +
+ Transceiver for one radio channel, serves 8 TS +
+
+TS +: +
+ Timeslots in the GSM radio interface; each runs a specific combination of logical channels +
+
+BSC +: +
+ Base Station Controller +
+

GSM Acronyms, Core Network

+MSC +: +
+ Mobile Switching Center; Terminates MM + CC Sub-layers +
+
+HLR +: +
+ Home Location Register; Subscriber Database +
+
+SMSC +: +
+ SMS Service Center +
+

GSM Acronyms, Layer 2 + 3

+LAPDm +: +
+ Link Access Protocol, D-Channel. Like LAPD in ISDN +
+
+RR +: +
+ Radio Resource (establish/release dedicated channels) +
+
+MM +: +
+ Mobility Management (registration, location, authentication) +
+
+CC +: +
+ Call Control (voice, circuit switched data, fax) +
+
+CM +: +
+ Connection Management +
+

Osmocom GSM components

Classic GSM network as digraph

Simplified OsmoNITB GSM network

which further reduces to the following minimal setup:

So our minimal setup is a Phone, a BTS and OsmoNITB.

Which BTS to use?

+ +Proprietary BTS of classic vendor + +
- + +Siemens BS-11 is what we started with + +
- + +Nokia, Ericsson, and others available 2nd hand + +
+
+ +OsmoBTS software implementation, running with + +
- + +Proprietary HW + PHY (DSP): sysmoBTS, or + +
- + +General purpose SDR (like USRP) + OsmoTRX + +
+

We assume a sysmoBTS in the following tutorial

OsmoBTS Overview

+ +Implementation of GSM BTS + +
+ +supports variety of hardware/PHY options + +
- + +osmo-bts-sysmo: BTS family by sysmocom + +
- + +osmo-bts-trx: Used with OsmoTRX + general-purpose SDR + +
- + +osmo-bts-octphy: Octasic OCTBTS hardware / OCTSDR-2G PHY + +
- + +osmo-bts-litecell15: Nutaq Litecell 1.5 hardware/PHY + +
+

See separate talk about BTS hardware options later today.

BTS Hardware vs. BTS software

+ +A classic GSM BTS is hardware + software + +
+ +It has two interfaces + +
- + +Um to the radio side, towards phones + +
- + +Abis to the wired back-haul side, towards BSC + +
+
+ +with today’s flexible architecture, this is not always true + +
- + +the hardware might just be a network-connected SDR and BTS software +runs o a different CPU/computer, or + +
- + +the BTS and BSC, or even the NITB may run on the same board + +
+

Physical vs. Logical Arch (sysmoBTS)

Physical vs. Logical Arch (SDR e.g. USRP B2xx)

IP layer traffic

+ +Abis/IP signaling runs inside IPA multiplex inside TCP + +
- + +Port 3002 and 3003 betewen BTS and BSC + +
- + +Connections initiated from BTS to BSC + +
+
+ +Voice data is carried in RTP/UDP on dynamic ports + +

⇒ Make sure you permit the above communication in your +network/firewall config

Configuring Osmocom software

+ +all native Osmo* GSM infrastructure programs share common architecture, as + defined by various libraries libosmo{core,gsm,vty,abis,netif,…} + +
+ +part of this is configuration handling + +
- + +interactive configuration via command line interface (vty), similar + to Cisco routers + +
- + +based on a fork of the VTY code from Zebra/Quagga, now libosmovty + +
+
+ +you can manually edit the config file, + +
+ +or use configure terminal and interactively change it + +

Configuring OsmoBTS

+ +OsmoBTS in our example scenario runs on the embedded ARM/Linux system + inside the sysmoBTS + +
+ +we access the sysmoBTS via serial console or ssh + +
+ +we then edit the configuration file /etc/osmocom/osmo-bts.cfg as + described in the following slide + +

Configuring OsmoBTS

bts 0
+ band DCS1800 <1>
+ ipa unit-id 1801 0 <2>
+ oml remote-ip 192.168.100.11 <3>

+
+the GSM frequency band in which the BTS operates +
+
+
+the unit-id by which this BTS identifies itself to the BSC +
+
+
+the IP address of the BSC (to establish the OML connection towards it) +
+

+ + + +

Note

All other configuration is downloaded by the BSC via OML. So most +BTS settings are configured in the BSC/NITB configuration file.

Purpose of Unit ID

+ +Unit IDs consist of three parts: + +
- + +Site Number, BTS Number, TRX Number + +
+

+ +source IP of all BTSs would be identical + +

⇒ BSC identifies BTS on Unit ID, not on Source IP!

Configuring OsmoNITB

+ +OsmoNITB is the osmo-nitb executable built from the openbsc + source tree / git repository + +
- + +just your usual git clone && autoreconf -fi && ./configure && make install + +
- + +(in reality, the libosmo* dependencies are required first…) + +
- + +nightly packages for Debian 8, Ubuntu 16.04 and 16.10 available + +
+
+ +OsmoNITB runs on any Linux system, like your speakers' laptop + +
- + +you can actually also run it on the ARM/Linux of the sysmoBTS itself, + having a literal Network In The Box with power as only external + dependency + +
+

Configuring OsmoNITB

network
+ network country code 1 <1>
+ mobile network code 1 <2>
+ short name Osmocom <3>
+ long name Osmocom
+ auth policy closed <4>
+ encryption a5 0 <5>

+
+MCC (Country Code) e.g. 262 for Germany; 1 == Test +
+
+
+MNC (Network Code) e.g. mcc=262, mnc=02 == Vodafone; 1 == Test +
+
+
+Operator name to be sent to the phone after registration +
+
+
+Only accept subscribers (SIM cards) explicitly authorized in HLR +
+
+
+Use A5/0 (== no encryption) +
+

Configuring BTS in OsmoNITB (BTS)

network
+ bts 0
+  type sysmobts <1>
+  band DCS1800 <2>
+  ms max power 33 <3>
+  periodic location update 6 <4>
+  ip.access unit_id 1801 0 <5>
+  codec-support fr hr efr amr <6>

+
+type of the BTS that we use (must match BTS) +
+
+
+frequency band of the BTS (must match BTS) +
+
+
+maximum transmit power phones are permitted (33 dBm == 2W) +
+
+
+interval at which phones should send periodic location update (6 minutes) +
+
+
+Unit ID of the BTS (must match BTS) +
+
+
+Voice codecs supported by the BTS +
+

Configuring BTS in OsmoNITB (TRX)

network
+ bts 0
+  trx 0
+   arfcn 871 <1>
+   max_power_red 0 <2>
+   timeslot 0
+    phys_chan_config CCCH+SDCCH4 <3>
+   timeslot 1
+    phys_chan_config TCH/F <4>
+    ...
+   timeslot 7
+    phys_chan_config PDCH <5>

+
+The RF channel number used by this TRX +
+
+
+The maximum power reduction in dBm. 0 = no reduction +
+
+
+Every BTS needs need one timeslot with a CCCH +
+
+
+We configure TS1 to TS6 as TCH/F for voice +
+
+
+We configure TS6 as PDCH for GPRS +
+

What a GSM phone does after power-up

+ +Check SIM card for last cell before switch-off + +
- + +if that cell is found again, use that + +
- + +if not, perform a network scan + +
  - + +try to find strong carriers, check if they contain BCCH + +
  - + +create a list of available cells + networks + +
  - + +if one of the networks MCC+MNC matches first digits of IMSI, this is +the home network, which has preference over others + +
  +
+
+ +perform LOCATION UPDATE (TYPE=IMSI ATTACH) procedure to network + +
+ +when network sends LOCATION UPDATE ACCEPT, camp on that cell + +

→ let’s check if we can perform LOCATION UPDATE on our own network

Verifying our network

+ +look at stderr of OsmoBTS and OsmoNITB + +
- + +OsmoBTS will terminate if Abis cannot be set-up + +
- + +expected to be re-spawned by init / systemd + +
+
+ +use MS to search for networks, try manual registration + +
+ +observe registration attempts logging level mm info + +

→ should show LOCATION UPDATE request / reject / accept

+ +use the VTY to explore system state (show *) + +
+ +use the VTY to change subscriber parameters like extension number + +

Exploring your GSM networks services

+ +use *#100# from any registered MS to obtain own number + +
+ +voice calls from mobile to mobile + +
+ +SMS from mobile to mobile + +
+ +SMS to/from external applications (via SMPP) + +
+ +voice to/from external PBX (via MNCC) + +
+ +explore the VTY interfaces of all network elements + +
- + +send SMS from the command line + +
- + +experiment with silent call feature + +
- + +experiment with logging levels + +
+
+ +use wireshark to investigate GSM protocols + +

Using the VTY

+ +The VTY can be used not only to configure, but also to interactively + explore the system status (show commands) + +
+ +Every Osmo* program has its own telnet port + +

+ +++ + + + + + + + + + + + + + + + + + + + + + +

Program	Telnet Port
OsmoPCU	4240
OsmoBTS	4241
OsmoNITB	4242
OsmoSGSN	4245

+ +ports are bound to 127.0.0.1 by default + +
+ +try tab-completion, ? and list commands + +

Using the VTY (continued)

+ +e.g. show subsciber to display data about subscriber: + +

OpenBSC> show subscriber imsi 901700000003804
+    ID: 12, Authorized: 1
+    Extension: 3804
+    LAC: 0/0x0
+    IMSI: 901700000003804
+    TMSI: F2D4FA0A
+    Expiration Time: Mon, 07 Dec 2015 09:45:16 +0100
+    Paging: not paging Requests: 0
+    Use count: 1

+ +try show bts, show trx, show lchan, show statistics, … + +

The End

+ +so long, and thanks for all the fish + +
+ +I hope you have questions! + +
+ +have fun exploring mobile technologies using Osmocom + +
+ +interested in working with more acronyms? Come join the project! + +
+ +Check out https://osmocom.org/ and openbsc@lists.osmocom.org + +

+ + diff --git a/2017/welcome_intro-osmocon2017/welcome_intro.adoc b/2017/welcome_intro-osmocon2017/welcome_intro.adoc index 70c9e43..6e918a1 100644 --- a/2017/welcome_intro-osmocon2017/welcome_intro.adoc +++ b/2017/welcome_intro-osmocon2017/welcome_intro.adoc @@ -12,6 +12,7 @@ image:images/osmocon.png[width="90%"] == A diverse audience +[role="incremental"] * Osmocom developers * Commercial cellular Operators * Community Wireless Network Operators @@ -22,11 +23,14 @@ image:images/osmocon.png[width="90%"] == Thanks to.. +[role="incremental"] * Heike for organization, backoffice, registration * Maike for ticket sales, registration * our hosts here at JGH Berlin * our Speakers -* the anonymous Sponsor of the travel grants +* the anonymous sponsor of the travel grants +* C3VOC of Chaos Computer Club for video recordings +* Everyone who ever contributed code to Osmocom! == Schedule @@ -103,7 +107,7 @@ Date: Tue Dec 23 20:25:15 2008 +0000 * organizes this event as Osmocom is no legal entity * unfortunately is doing >= 80% of commits in Osmocom cellular infrastructure projects. -** Osmocom must not depend on sysmocom +** Osmocom should not depend on sysmocom ** we need more commitment and contributions from all users and beneficiaries == EOF diff --git a/2017/welcome_intro-osmocon2017/welcome_intro.html b/2017/welcome_intro-osmocon2017/welcome_intro.html new file mode 100644 index 0000000..1f0a70b --- /dev/null +++ b/2017/welcome_intro-osmocon2017/welcome_intro.html @@ -0,0 +1,4205 @@ + + + + +Welcome to Osmocom Conference 2017 + + + + + + + + +

Welcome to Osmocom Conference 2017

+ images/osmocon.png +

A diverse audience

+ +Osmocom developers + +
+ +Commercial cellular Operators + +
+ +Community Wireless Network Operators + +
+ +IT Security + +
+ +Academia / Research + +
+ +Vendors of BTS hardware / PHY layers + +
+ +M2M / IoT Device Testing + +

Thanks to..

+ +Heike for organization, backoffice, registration + +
+ +Maike for ticket sales, registration + +
+ +our hosts here at JGH Berlin + +
+ +our Speakers + +
+ +the anonymous sponsor of the travel grants + +
+ +C3VOC of Chaos Computer Club for video recordings + +
+ +Everyone who ever contributed code to Osmocom! + +

Schedule

+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +

10:00	10:30	Morning Break
12:30	13:30	Lunch Break
15:30	16:00	Afternoon Break
19:30	-	Social event (doors)
20:00	-	Social event (food)

and lots of technical talks in between, of course

Social Event

+ +Address + +

Restaurant "Zur Gerichtslaube"
+Poststr. 28
+10178 Berlin

+ +We have leaflets with map + address informations + +
+ +Get there: By yourself, using public transport or cabs + +
+ +Vegetarian + Vegan option available upon request + +

Where do we come from?

+ +2008: Humble beginnings with bs11_abis + bsc_hack + +
- + +Dieter Spaar + Harald Welte start with old Siemens BS-11 and ISDN-Card + +
- + +implement whatever needed beyond the BTS to simulate a telephony network + +
- + +turned into OpenBSC in December 2008 + +
+

commit 52b1f9888905df8aa6ecd50af900b63f5273de6a
+Author: Harald Welte <laforge@gnumonks.org>
+Date:   Tue Dec 23 20:25:15 2008 +0000
+
+    initial commit of current OpenBSC state

From OpenBSC to Osmocom

+ +2009: OpenBSC code matures beyond PoC + +
+ +2009: Support for ip.access nanoBTS + +
- + +first multi-vendor BSC to our knowledge + +
+
+ +2010: OsmocomBB project starts for phone-side GSM stack + +
+ +Start of Osmocom as umbrella project for OpenBSC + OsmocomBB + +

Osmocom 101

+ +umbrella project for O pen S ource MO bile COM munications + +
+ +FOSS developers exploring mobile communications + +
+ +much larger than the Cellular Infrastructure projects we talk about today + +
- + +TETRA, Thuraya, DECT, OP25, SDR, SIMtrace and many others + +
- + +59 projects in https://osmocom.org/ redmine + +
- + +112 git repositories on https://git.osmocom.org/ + +
+
+ +most well-known typically OsmocomBB, OpenBSC + rtl-sdr + +

Community + Collaborative Development

+ +Free Software is about collaborative development + +
- + +shared investment in R&D, while everyone can use full results + +
- + +it is not about a one-way producer/consumer relationship + +
+
+ +sustainable projects need serious committment contributions from all + stake holders + +

sysmocom - s.f.m.c. GmbH

+ +founded in 2011 by two core Osmocom developers + +
+ +exists to drive/support Osmocom development + +
+ +does not claim (nor want) ownership over any part of Osmocom + +
+ +organizes this event as Osmocom is no legal entity + +
+ +unfortunately is doing >= 80% of commits in Osmocom cellular + infrastructure projects. + +
- + +Osmocom must not depend on sysmocom + +
- + +we need more commitment and contributions from all users and beneficiaries + +
+

EOF

End of File

+ + -- cgit v1.2.3