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

[[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
|===

[[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>>
| 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
|===

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