1149 lines
40 KiB
Plaintext
1149 lines
40 KiB
Plaintext
== 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 48.058.
|
|
|
|
==== Messages Compliant With TS 48.058
|
|
|
|
Specific additions and limitations apply, see the linked sections.
|
|
|
|
.Messages compliant with TS 48.058
|
|
[options="header",cols="10%,20%,45%,5%,20%"]
|
|
|===
|
|
| TS 48.058 § | 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>> | CHANNEL ACTIVATION | <- | Received
|
|
| 8.4.2 | <<CHANNEL_ACTIVATION>> | CHANNEL ACTIVATION ACKNOWLEDGE | -> | Sent
|
|
| 8.4.3 | <<CHANNEL_ACTIVATION>> | 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.16 | - | BS 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.4 | - | DELETE INDICATION | -> | Sent
|
|
| 8.5.5 | <<PAGING_COMMAND>> | PAGING COMMAND | <- | Received
|
|
| 8.5.6 | - | IMMEDIATE ASSIGN COMMAND | <- | Received
|
|
| 8.5.8 | - | SMS BROADCAST COMMAND | <- | Received
|
|
| 8.5.9 | - | CBCH LOAD INDICATION | -> | Sent
|
|
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 48.058
|
|
[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
|
|
5+<| *IPA style PDCH Management* (<<ipa_style_pdch_mgmt>>)
|
|
.3+.| <<pdch_act>> | <<rsl_pdch_act>> | RSL PDCH Activation | <- | Received
|
|
| <<rsl_pdch_act_ack>> | RSL PDCH Activation ACK | -> | Sent
|
|
| <<rsl_pdch_act_nack>> | RSL PDCH Activation NACK | -> | Sent
|
|
.3+.| <<pdch_deact>> | <<rsl_pdch_deact>> | RSL PDCH Deactivation | <- | Received
|
|
| <<rsl_pdch_deact_ack>> | RSL PDCH Deactivation ACK | -> | Sent
|
|
| <<rsl_pdch_deact_nack>> | RSL PDCH Deactivation NACK | -> | Sent
|
|
5+<| *COMMON CHANNEL MANAGEMENT MESSAGES*
|
|
.3+.| <<etws>> | <<OSMO_ETWS_CMD>> | Osmocom ETWS Command | <- | Received
|
|
|===
|
|
|
|
==== Messages Not Implemented by OsmoBTS
|
|
|
|
.3GPP TS 48.058 messages not implemented by OsmoBTS
|
|
[options="header",cols="10%,90%"]
|
|
|===
|
|
| TS 48.058 § | Message
|
|
2+<| *DEDICATED CHANNEL MANAGEMENT MESSAGES*
|
|
| 8.4.12 | PHYSICAL CONTEXT REQUEST
|
|
| 8.4.13 | PHYSICAL CONTEXT CONFIRM
|
|
| 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 ACKNOWLEDGE
|
|
| 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.7 | SMS BROADCAST REQUEST
|
|
| 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
|
|
|
|
[[CHANNEL_ACTIVATION]]
|
|
==== Channel Activation
|
|
|
|
When used on a timeslot using the non-standard channel combination
|
|
'NM_CHANC_OSMO_DYN' as configured by OML, the regular
|
|
RSL channel activation procedures can not only be used for activation
|
|
of circuit-switched channels, but also for activation of a PDCH.
|
|
|
|
See <<OSMOCOM_DYN_TS>>.
|
|
|
|
NOTE:: Do not confuse this with the IPA style _PDCH ACT_ type
|
|
dynamic PDCH protocol employed by nanoBTS devices (<<ipa_style_pdch_mgmt>>).
|
|
|
|
[[MEASUREMENT_RESULT]]
|
|
==== Measurement Result
|
|
|
|
Conforms to 3GPP TS 48.058 § 8.4.8 with this limitation:
|
|
|
|
._Measurement Result_ IE limitations
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | IE Name | Handling
|
|
| 9.3.37 | MS Timing Offset | never sent by OsmoBTS
|
|
|===
|
|
|
|
[[MODE_MODIFY]]
|
|
==== Mode Modify
|
|
|
|
Conforms to 3GPP TS 48.058 § 8.4.9 with these limitations:
|
|
|
|
._Mode Modify_ IE limitations
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | 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 48.058 § 8.4.15 with these limitations:
|
|
|
|
._MS Power Control_ IE limitations
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | IE Name | Handling
|
|
| 9.3.31 | MS Power Parameters | _ignored_
|
|
|===
|
|
|
|
|
|
[[SACCH_INFO_MODIFY]]
|
|
==== SACCH Info Modify
|
|
|
|
Conforms to 3GPP TS 48.058 § 8.4.20, with these exceptions:
|
|
|
|
._SACCH Info Modify_ IE limitations
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | 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
|
|
| 0x0f | RSL_SYSTEM_INFO_10
|
|
| 0x47 | RSL_EXT_MEAS_ORDER
|
|
| 0x48 | RSL_MEAS_INFO
|
|
|===
|
|
|
|
[[BCCH_INFORMATION]]
|
|
==== BCCH Information
|
|
|
|
Conforms to 3GPP TS 48.058 § 8.5.1, with these limitations and extensions:
|
|
|
|
._BCCH Information_ IE details
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | 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 48.058 § 8.5.3, with these limitations:
|
|
|
|
._Channel Required_ message IE details
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | IE Name | Handling
|
|
| 9.3.16 | Physical Context | never sent by OsmoBTS
|
|
|===
|
|
|
|
|
|
[[PAGING_COMMAND]]
|
|
==== Paging Command
|
|
|
|
Conforms to 3GPP TS 48.058 § 8.5.5, with these limitations:
|
|
|
|
._Paging Command_ message IE details
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | 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.
|
|
|
|
|
|
[[RF_RESOURCE_INDICATION]]
|
|
==== RF Resource Indication
|
|
|
|
For all osmo-bts variants, except osmo-bts-trx, this message does not conform
|
|
to 3GPP TS 48.058 § 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 48.058 § | IE Name | Handling
|
|
| 9.3.21 | Resource Information | DSP based osmo-bts variants omit this IE, though
|
|
TS 48.058 specifies it as mandatory.
|
|
|===
|
|
|
|
|
|
[[SACCH_FILLING]]
|
|
==== SACCH Filling
|
|
|
|
Conforms to 3GPP TS 48.058 § 8.6.2, with these limitations:
|
|
|
|
._SACCH Filling_ message IE limitations
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | 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 48.058 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 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>>
|
|
|
|
|
|
[[rsl-dynamic-channels]]
|
|
=== Dynamic Channel Combinations
|
|
|
|
In the classic data model established by ETSI/3GPP for A-bis, each
|
|
timeslot (channel) is configured using a static channel combination by
|
|
means of A-bis OML. Particularly in presence of GPRS services, this
|
|
is very inflexible and leads to inefficient use of air interface
|
|
resources.
|
|
|
|
As such, several methods have been implemented to overcome this
|
|
limitation. The fundamental operation can be outlined like this:
|
|
|
|
* Configuration of a particular _dynamic_ channel combination via OML
|
|
* activation of TCH works like on a classic TCH channel combination
|
|
* activation of PDCH requires some specific PDCH activation procedure
|
|
|
|
There are two variants implemented in the OsmoBTS A-bis dialect:
|
|
|
|
[[ipa_style_pdch_mgmt]]
|
|
==== IPA Style Dynamic Channels
|
|
|
|
This method is used when OML uses 'NM_CHANC_IPAC_TCHFull_PDCH' (0x80)
|
|
as channel combination for the given time-slot.
|
|
|
|
'IPA style' refers to 'ip.access' compatible PDCH activation and deactivation.
|
|
|
|
When the IPA style dynamic channel combination _TCH/F or PDCH_
|
|
is set, the non-standard 'PDCH ACTIVATE' (<<pdch_act>>) and 'PDCH
|
|
DEACTIVATE' (<<pdch_deact>>) procedures are used for switching an idle
|
|
channel into PDCH mode and back into idle mode.
|
|
|
|
When the channel is used as TCH/F, regular circuit-switched activation
|
|
is performed, like on any traditional TCH/F. However, the BSC must
|
|
make sure to first disable the PDCH on the timeslot, before activating
|
|
it as TCH/F. Likewise, any circuit-switched TCH/F on the channel must
|
|
be deactivated using standard RSL signalling, before the specific PDCH
|
|
related procedures are used to enable the PDCH.
|
|
|
|
[[pdch_act]]
|
|
===== PDCH Activate
|
|
|
|
This procedure is used by the BSC to request the BTS to activate an
|
|
IPA style dynamic TCH/F+PDCH channel in PDCH mode.
|
|
|
|
The operation is not supported on any other physical channel type.
|
|
|
|
See <<rsl_pdch_act>>, <<rsl_pdch_act_ack>>, <<rsl_pdch_act_nack>>
|
|
|
|
[[pdch_deact]]
|
|
===== PDCH Deactivate
|
|
|
|
This procedure is used by the BSC to request the BTS to deactivate an
|
|
active PDCH on any an IPA style dynamic TCH/F+PDCH channel.
|
|
|
|
The operation is not supported on any other physical channel type.
|
|
|
|
See <<rsl_pdch_deact>>, <<rsl_pdch_deact_ack>>, <<rsl_pdch_deact_nack>>
|
|
|
|
===== IPA Style Dynamic Switchover Example
|
|
|
|
.Part 1: example for dynamic channel switchover, for IPA style dynamic timeslots
|
|
["mscgen"]
|
|
----
|
|
include::dyn_ts_ipa_style1.msc[]
|
|
----
|
|
|
|
.Part 2: example for dynamic channel switchover, for IPA style dynamic timeslots
|
|
["mscgen"]
|
|
----
|
|
include::dyn_ts_ipa_style2.msc[]
|
|
----
|
|
|
|
|
|
[[OSMOCOM_DYN_TS]]
|
|
==== Osmocom Style Dynamic Channels
|
|
|
|
This method is in use when OML uses
|
|
'NM_CHANC_OSMO_DYN' (0x90) for the given time-slot.
|
|
|
|
The activation of PDCH is performed by using the regular 'RSL CHANNEL ACTIVATE'
|
|
procedure according to <<CHANNEL_ACTIVATION>>, with these modifications:
|
|
|
|
* The 'C-bits' part of the 'Channel Number' IE take the non-standard binary
|
|
value 11000 (C5 through C1 as seen in 3GPP TS 48.058 § 9.3.1).
|
|
* The 'A-bits' part of the 'Activation Type' IE take the non-standard binary
|
|
value 1111, with an additional fourth bit (add A4 to A3 through A1 as seen in
|
|
3GPP TS 48.058 § 9.3.3; all remaining reserved bits as well as the 'R' bit are
|
|
coded as zero).
|
|
* The normally mandatory 'Channel Mode' IE is omitted; none of the optional IEs
|
|
are included.
|
|
|
|
Hence the message consists of exactly these IEs:
|
|
|
|
.PDCH type _Channel Activation_ message IEs
|
|
[options="header",cols="10%,30%,60%"]
|
|
|===
|
|
| TS 48.058 § | IE Name | Handling
|
|
| 9.1 | Message discriminator | Dedicated Channel Management
|
|
| 9.2 | Message type | CHANnel ACTIVation
|
|
| 9.3.1 | Channel number | 'C-bits' 11000, plus TS bits as usual
|
|
| 9.3.3 | Activation type | 'A-bits' 1111
|
|
|===
|
|
|
|
===== Osmocom Style Dynamic Switchover Example
|
|
|
|
.Part 1: example for dynamic channel switchover, for Osmocom style dynamic timeslots
|
|
["mscgen"]
|
|
----
|
|
include::dyn_ts_osmocom_style1.msc[]
|
|
----
|
|
|
|
.Part 2: example for dynamic channel switchover, for Osmocom style dynamic timeslots
|
|
["mscgen"]
|
|
----
|
|
include::dyn_ts_osmocom_style2.msc[]
|
|
----
|
|
|
|
[[etws]]
|
|
=== ETWS (Earthquake and Tsunami Warning System)
|
|
|
|
ETWS as specified in 3GPP TS 23.041 includes not only notification via
|
|
SMSCB, but also so-called Primary Notifications (PN). The ETWS PN are
|
|
transmitted
|
|
|
|
* by the BSC to all subscribers with active dedicated channels
|
|
* by the BTS on the PCH to all subscribers in idle mode
|
|
* by the PCU on the PACCH to all subscribers with active TBF
|
|
|
|
Unfortunately, 3GPP forgot to update their specifications with any
|
|
information as to how the ETWS PN is transmitted from BSC to BTS in
|
|
a portable way, and Osmocom had to invent their own non-standard
|
|
signaling for it.
|
|
|
|
See <<OSMO_ETWS_CMD>> for the Osmocom implementation.
|
|
|
|
|
|
=== BCCH carrier power reduction operation
|
|
|
|
According to 3GPP TS 45.008, section 7.1, the BCCH carrier (sometimes called C0) of
|
|
a BTS shall maintain discontinuous Downlink transmission at full power in order to
|
|
stay "visible" to the mobile stations. Because of that, early versions of this 3GPP
|
|
document prohibited BS power reduction on C0. However, a new feature was introduced
|
|
version 13.0.0 (2015-11) - "BCCH carrier power reduction operation".
|
|
|
|
This is a special mode of operation, in which the variation of RF power level for
|
|
some timeslots is relaxed for the purpose of energy saving. In other words, the
|
|
output power on some timeslots, except the timeslot(s) carrying BCCH/CCCH, can be
|
|
lower than the full power. In this case the maximum allowed difference is 6 dB.
|
|
|
|
Unfortunately, 3GPP did not specify in which way the BTS is instructed to activate
|
|
and deactivate the BCCH carrier power reduction mode. Osmocom had to invent their
|
|
own non-standard approach: the BSC needs to send _BS POWER CONTROL_ message with
|
|
the _Channel Number_ IE set to 0x80 (BCCH) and the _Message Discriminator_ set to
|
|
0x06 (Common Channel Management messages).
|
|
|
|
|
|
=== Message Formats and Contents
|
|
|
|
[[rsl_crcx_msg]]
|
|
==== Create Connection (CRCX)
|
|
|
|
This message is sent by the BSC to the BTS 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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
|
|
| RTP CSD Format | <<RSL_IE_IPAC_RTP_CSD_FORMAT>> | O | TV | 2
|
|
|===
|
|
|
|
[[rsl_crcx_msg_ack]]
|
|
==== Create Connection (CRCX) ACK
|
|
|
|
This message is sent by the BTS to the BSC 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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 | 48.058 9.3.26 | O | TLV | >= 3
|
|
|===
|
|
|
|
|
|
[[rsl_mdcx_msg]]
|
|
==== Modify Connection (MDCX)
|
|
|
|
This message is sent by the BSC to the BTS 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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
|
|
| RTP CSD Format | <<RSL_IE_IPAC_RTP_CSD_FORMAT>> | O | TV | 2
|
|
|===
|
|
|
|
[[rsl_mdcx_msg_ack]]
|
|
==== Modify Connection (MDCX) ACK
|
|
|
|
This message is sent by the BTS to the BSC 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
| Cause | 48.058 9.3.26 | M | TLV | >= 3
|
|
|===
|
|
|
|
[[rsl_dlcx_ind_msg]]
|
|
==== Delete Connection (DLCX) Indication
|
|
|
|
This message is sent by the BTS 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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 | 48.058 9.3.26 | M | TLV | >= 3
|
|
|===
|
|
|
|
[[rsl_dlcx_msg]]
|
|
==== Delete Connection (DLCX)
|
|
|
|
This message is sent by the BSC to the BTS 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 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 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 | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
| Connection Id | <<RSL_IE_IPAC_CONN_ID>> | O | TV | 3
|
|
| Cause | 48.058 9.3.26 | M | TLV | >= 3
|
|
|===
|
|
|
|
[[rsl_pdch_act]]
|
|
==== PDCH Activate
|
|
|
|
This message is sent by the BSC to request the activation of a PDCH on
|
|
a IPA style dynamic TCH/F+PDCH channel.
|
|
|
|
[options="header"]
|
|
[cols="30%,25%,15%,15%,15%"]
|
|
|===
|
|
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
|
| Message discriminator | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
|===
|
|
|
|
NOTE:: This message is *not* used by Osmocom style dynamic channels
|
|
|
|
[[rsl_pdch_act_ack]]
|
|
==== PDCH Activate ACK
|
|
|
|
This message is sent by the BTS to confirm the successful activation
|
|
of a PDCH on a IPA style dynamic TCH/F+PDCH channel.
|
|
|
|
[options="header"]
|
|
[cols="30%,25%,15%,15%,15%"]
|
|
|===
|
|
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
|
| Message discriminator | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
| Frame Number | 48.058 9.3.8 | O | TV | 3
|
|
|===
|
|
|
|
NOTE:: This message is *not* used by Osmocom style dynamic channels
|
|
|
|
[[rsl_pdch_act_nack]]
|
|
==== PDCH Activate NACK
|
|
|
|
This message is sent by the BTS to reject the successful activation
|
|
of a PDCH on a IPA style dynamic TCH/F+PDCH channel.
|
|
|
|
[options="header"]
|
|
[cols="30%,25%,15%,15%,15%"]
|
|
|===
|
|
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
|
| Message discriminator | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
| Cause | 48.058 9.3.26 | M | TLV | >= 3
|
|
|===
|
|
|
|
NOTE:: This message is *not* used by Osmocom style dynamic channels
|
|
|
|
[[rsl_pdch_deact]]
|
|
==== PDCH Deactivate
|
|
|
|
This message is sent by the BSC to request the deactivation of a PDCH
|
|
on a IPA style dynamic TCH/F+PDCH channel.
|
|
|
|
[options="header"]
|
|
[cols="30%,25%,15%,15%,15%"]
|
|
|===
|
|
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
|
| Message discriminator | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
|===
|
|
|
|
NOTE:: This message is *not* used by Osmocom style dynamic channels
|
|
|
|
[[rsl_pdch_deact_ack]]
|
|
==== PDCH Deactivate ACK
|
|
|
|
This message is sent by the BTS to confirm the successful deactivation
|
|
of a PDCH on a IPA style dynamic TCH/F+PDCH channel.
|
|
|
|
[options="header"]
|
|
[cols="30%,25%,15%,15%,15%"]
|
|
|===
|
|
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
|
| Message discriminator | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
|===
|
|
|
|
NOTE:: This message is *not* used by Osmocom style dynamic channels
|
|
|
|
[[rsl_pdch_deact_nack]]
|
|
==== PDCH Deactivate NACK
|
|
|
|
This message is sent by the BTS to reject the deactivation of a PDCH
|
|
on a IPA style dynamic TCH/F+PDCH channel.
|
|
|
|
[options="header"]
|
|
[cols="30%,25%,15%,15%,15%"]
|
|
|===
|
|
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
|
| Message discriminator | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
| Cause | 48.058 9.3.26 | M | TLV | >= 3
|
|
|===
|
|
|
|
NOTE:: This message is *not* used by Osmocom style dynamic channels
|
|
|
|
[[OSMO_ETWS_CMD]]
|
|
==== Osmocom ETWS Command
|
|
|
|
This message is sent by the BSC to transfer the ETWS Primary Notification (PN)
|
|
from BSC to BTS and enable/disable transmission of ETWS PN by the BTS. For more
|
|
information about ETWS, see 3GPP TS 23.041.
|
|
|
|
If the ETWS PN length is > 0, the BTS will immediately start transmission
|
|
of the received ETWS PN on the PCH using P1 Rest Octets. It will also forward
|
|
he ETWS PN to the PCU to enable the PCU to transmit it via PACCH on active TBF.
|
|
|
|
If the ETWS PN length is 0, the BTS will stop any ETWS PN broadcast via the PCH.
|
|
|
|
The Channel Number IE is set to the Downlink CCCH (PCH).
|
|
|
|
[options="header"]
|
|
[cols="30%,25%,15%,15%,15%"]
|
|
|===
|
|
| INFORMATION ELEMENT | REFERENCE | PRESENCE | FORMAT | LENGTH
|
|
| Message discriminator | 48.058 9.1 | M | V | 1
|
|
| Message type | <<own_msg_types>> | M | V | 1
|
|
| Channel number | 48.058 9.3.1 | M | TV | 2
|
|
| SMSCB Message | 48.058 9.3.42 | M | TLV | 2-58
|
|
|===
|
|
|
|
|
|
=== Information Element Codings
|
|
|
|
[[own_msg_types]]
|
|
==== A-bis/IP specific RSL Message discriminators
|
|
|
|
The following message discriminators are used in addition to those
|
|
indicated in 3GPP TS 48.058 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>>
|
|
| 0x7f | Osmocom ETWS Command | <<OSMO_ETWS_CMD>>
|
|
| 0x48 | PDCH Activate | <<rsl_pdch_act>>
|
|
| 0x49 | PDCH Activate ACK | <<rsl_pdch_act_ack>>
|
|
| 0x4a | PDCH Activate NACK | <<rsl_pdch_act_nack>>
|
|
| 0x4b | PDCH Deactivate | <<rsl_pdch_deact>>
|
|
| 0x4c | PDCH Deactivate ACK | <<rsl_pdch_deact_ack>>
|
|
| 0x4d | PDCH Deactivate NACK | <<rsl_pdch_deact_nack>>
|
|
|===
|
|
|
|
==== A-bis/IP specific RSL IEIs
|
|
|
|
The following Information Element Identifiers (IEIs) are used in
|
|
addition to those indicated in 3GPP TS 48.058 Section 9.3:
|
|
|
|
.A-bis/IP specific information elements
|
|
[options="header",cols="10%,50%,40%"]
|
|
|===
|
|
| IEI | Name | This document §
|
|
| 0x01 | RSL_IE_CHAN_NR | <<RSL_IE_CHAN_NR>>
|
|
| 0x60 | RSL_IE_OSMO_REP_ACCH_CAP | <<RSL_IE_OSMO_REP_ACCH_CAP>>
|
|
| 0x61 | RSL_IE_OSMO_TRAINING_SEQUENCE | <<RSL_IE_OSMO_TRAINING_SEQUENCE>>
|
|
| 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>>
|
|
| 0xf9 | RSL_IE_IPAC_RTP_CSD_FORMAT | <<RSL_IE_IPAC_RTP_CSD_FORMAT>>
|
|
| 0xfc | RSL_IE_IPAC_RTP_PAYLOAD2 | <<RSL_IE_IPAC_RTP_PAYLOAD2>>
|
|
|===
|
|
|
|
[[RSL_IE_CHAN_NR]]
|
|
==== RSL_IE_CHAN_NR
|
|
|
|
This information element is coded as described in 3GPP TS 48.058 Section 9.3.1,
|
|
but in addition supports the following vendor specific values:
|
|
|
|
.RSL Channel Number extensions
|
|
[options="header",cols="5%,5%,5%,5%,5%,75%"]
|
|
|===
|
|
| C5 | C4 | C3 | C2 | C1 | Description
|
|
| 1 | 1 | 0 | 0 | 0 | PDCH `<1>`
|
|
| 1 | 1 | 0 | 0 | 1 | CBCH on SDCCH4
|
|
| 1 | 1 | 0 | 1 | 0 | CBCH on SDCCH8
|
|
| 1 | 1 | 1 | 0 | 1 | VAMOS TCH/F `<2>`
|
|
| 1 | 1 | 1 | 1 | T | VAMOS TCH/H `<2>`
|
|
|===
|
|
|
|
`<1>` This extension is only valid on an Osmocom-style dynamic channel, having
|
|
configured the 'NM_CHANC_IPAC_TCHFull_PDCH' channel combination by OML.
|
|
`<2>` These Osmocom specific values are used by osmo-bsc to address logical
|
|
channels on the shadow timeslots in VAMOS mode, iff the BTS is an osmo-bts
|
|
and VAMOS capable.
|
|
|
|
The TN-Bits are not re-defined in this case but use the same encoding
|
|
as specified in TS 48.058 Section 9.3.1.
|
|
|
|
|
|
[[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 30 bytes, with the first byte as IEI, the second byte as length
|
|
(=28), 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 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.
|
|
|
|
[[RSL_IE_OSMO_REP_ACCH_CAP]]
|
|
==== RSL_IE_OSMO_REP_ACCH_CAP
|
|
|
|
This is a one byte length TLV IE that is used to enable or disable repeated ACCH
|
|
capabilities on the BTS side during Channel Activation and Mode Modify.
|
|
|
|
The IE contains a bitfield in the lower nibble in order to set the ACCH repetition
|
|
policy for each of the two channel types individually. Depending on the state of the
|
|
bits (see table below) the ACCH repetition mode is either enabled or disabled completely.
|
|
|
|
The lower 3 bit of the higher nibble are used to signal an RXQUAL threshold to set the
|
|
BER on which UL-SACCH or DL-FACCH repetition shall be turned on. If the field is set
|
|
to 0, then UL-SACCH and DL-FACCH will be always on. DL-FACCH will also be turned on
|
|
automatically as soon as the MS requests a DL-SACCH repetition.
|
|
|
|
If the IE is not present, then ACCH repetition completely is disabled.
|
|
|
|
[options="header"]
|
|
|===
|
|
| *bit* | 7 | 6 - 4 | 3 | 2 | 1 | 0
|
|
| byte at offset 0 | 0 | RXQUAL | UL-SACCH | DL-SACCH | DL-FACCH/ALL | DL-FACCH/CMD
|
|
|===
|
|
|
|
(Bits 7 is reserved for future use and must be set to zero.)
|
|
|
|
[[RSL_IE_OSMO_TRAINING_SEQUENCE]]
|
|
==== RSL_IE_OSMO_TRAINING_SEQUENCE
|
|
|
|
This TLV IE instructs the BTS to use a specific training sequence set and
|
|
training sequence code for a given lchan. It is sent by OsmoBSC in RSL CHANNEL
|
|
ACTIVATION and MODE MODIFY messages to the BTS, iff the BTS is VAMOS-capable,
|
|
i.e. if an Abis-over-IP connected BTS indicated BTS_FEAT_VAMOS in the OML BTS
|
|
features (Manufacturer Id information element, see <<NM_ATT_MANUF_ID>>).
|
|
|
|
If this information element is present, the receiver shall ignore any other
|
|
training sequence set and training sequence code bits from other information
|
|
elements of the same RSL message.
|
|
|
|
This is an Osmocom-specific extension of the RSL layer, which was added to
|
|
express more than two TSC sets. For VAMOS operation, OsmoBSC selects from one
|
|
of four separate training sequence codings per modulation scheme, while usual
|
|
RSL IEs are only able to express a single-bit TSC set number. For clarity, this
|
|
IE contains both the TSC set and the TSC in one IE, and is defined as
|
|
overruling any other IEs containing TSC or TSC set numbers.
|
|
|
|
The first value octet indicates the training sequence set, and the second octet
|
|
indicates the training sequence code to be used. Receiving values from a
|
|
reserved value range should be considered an error condition.
|
|
|
|
.RSL_IE_OSMO_TRAINING_SEQUENCE
|
|
[options="header",width="80%",cols="20%,80%"]
|
|
|===
|
|
| IE octet | value
|
|
| octet 1 | RSL_IE_OSMO_TRAINING_SEQUENCE IEI (0x61)
|
|
| octet 2 | length of the value part (2)
|
|
| octet 3 | TSC set
|
|
| octet 4 | TSC
|
|
|===
|
|
|
|
The training sequence set (TSC set) is coded like the 'CS Domain TSC Set' bits,
|
|
as defined in the 'Extended TSC Set' IE in 3GPP TS 44.018 10.5.2.82
|
|
<<3gpp-ts-44-018>>, and corresponds to the 'TSC Set' as defined in 3GPP TS
|
|
45.002 <<3gpp-ts-45-002>>. The encoded training sequence set number ranges from
|
|
0 to 3, any other values are reserved for future use. The encoded 0 corresponds
|
|
to TSC Set 1, see <<RSL_IE_OSMO_TRAINING_SEQUENCE__TSC_set_coding>>.
|
|
|
|
[[RSL_IE_OSMO_TRAINING_SEQUENCE__TSC_set_coding]]
|
|
.TSC set (octet 3) coding
|
|
[options="header",width="80%",cols="20%,80%"]
|
|
|===
|
|
| octet 3 value | interpretation
|
|
| 0 | 'TSC Set 1' as in 3GPP TS 45.002
|
|
| 1 | 'TSC Set 2'
|
|
| 2 | 'TSC Set 3'
|
|
| 3 | 'TSC Set 4'
|
|
| 4..255 | reserved values
|
|
|===
|
|
|
|
The training sequence code (TSC) corresponds to the 'TSC' bits as defined in
|
|
the 'Channel Description 2' IE in 3GPP TS 44.018 10.5.2.5a <<3gpp-ts-44-018>>.
|
|
The training sequence code ranges from 0 to 7, any other values are reserved
|
|
for future use.
|
|
|
|
.TSC (octet 4) coding
|
|
[options="header",width="80%",cols="20%,80%"]
|
|
|===
|
|
| octet 4 value | interpretation
|
|
| 0 | 'Training Sequence Code (TSC) 0' as in 3GPP TS 45.002
|
|
| 1 | 'Training Sequence Code (TSC) 1'
|
|
| 2 | 'Training Sequence Code (TSC) 2'
|
|
| 3 | 'Training Sequence Code (TSC) 3'
|
|
| 4 | 'Training Sequence Code (TSC) 4'
|
|
| 5 | 'Training Sequence Code (TSC) 5'
|
|
| 6 | 'Training Sequence Code (TSC) 6'
|
|
| 7 | 'Training Sequence Code (TSC) 7'
|
|
| 8..255 | reserved values
|
|
|===
|
|
|
|
[[RSL_IE_IPAC_RTP_CSD_FORMAT]]
|
|
==== RSL_IE_IPAC_RTP_CSD_FORMAT
|
|
|
|
This information element contains the RTP Circuit Switched Data format.
|
|
|
|
.A-bis/IP RTP CSD Format
|
|
[options="header",width="60%",cols="15%,15%,70%"]
|
|
|===
|
|
| Offset | Size | Description
|
|
| 0 | 4 | RTP CSD Format D
|
|
| 4 | 4 | RTP CSD Format IR
|
|
|===
|
|
|
|
.A-bis/IP RTP CSD Format D Values
|
|
[options="header",width="40%",cols="20%,80%"]
|
|
|===
|
|
| Value | Description
|
|
| 0 | External TRAU format
|
|
| 1 | Non-TRAU Packed format
|
|
| 2 | TRAU within the BTS
|
|
| 3 | IWF-Free BTS-BTS Data
|
|
|===
|
|
|
|
.A-bis/IP RTP CSD Format IR Values
|
|
[options="header",width="40%",cols="20%,80%"]
|
|
|===
|
|
| Value | Description
|
|
| 0 | 8 kb/s
|
|
| 1 | 16 kb/s
|
|
| 2 | 32 kb/s
|
|
| 3 | 48 kb/s
|
|
|===
|
|
|
|
=== 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[]
|
|
----
|
|
|
|
The initialization of the primary and secondary TRX slightly differ, as
|
|
illustrated by the differences of <<rsl-msc-pri>> and <<rsl-msc-sec>>.
|
|
Since the secondary TRX has no BCCH, it does not (need to) receive any 'RSL
|
|
BCCH INFORMATION' messages from the BSC.
|