== 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 | <- | Received | 8.4.2 | <> | CHANNEL ACTIVATION ACKNOWLEDGE | -> | Sent | 8.4.3 | <> | CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE | -> | Sent | 8.4.4 | - | CONNECTION FAILURE INDICATION | -> | Sent | 8.4.5 | - | DEACTIVATE SACCH | <- | Received | 8.4.6 | - | ENCRYPTION COMMAND | <- | Received | 8.4.7 | - | HANDOVER DETECTION | -> | Sent | 8.4.8 | <> | MEASUREMENT RESULT | -> | Sent | 8.4.9 | <> | 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 | <- | Received | 8.4.16 | - | BS POWER CONTROL | <- | Received | 8.4.19 | - | RF CHANNEL RELEASE ACKNOWLEDGE | -> | Sent | 8.4.20 | <> | SACCH INFO MODIFY | <- | Received 5+<| *COMMON CHANNEL MANAGEMENT MESSAGES* | 8.5.1 | <> | BCCH INFORMATION | <- | Received | 8.5.2 | - | CCCH LOAD INDICATION | -> | Sent | 8.5.3 | <> | CHANNEL REQUIRED | -> | Sent | 8.5.4 | - | DELETE INDICATION | -> | Sent | 8.5.5 | <> | 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 | -> | Sent | 8.6.2 | <> | 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* (<>) .3+.| <> | <> | RSL Create Connection (CRCX) | <- | Received | <> | RSL Create Connection (CRCX) ACK | -> | Sent | <> | RSL Create Connection (CRCX) NACK | -> | Sent .3+.| <> | <> | RSL Modify Connection (MDCX) | <- | Received | <> | RSL Modify Connection (MDCX) ACK | -> | Sent | <> | RSL Modify Connection (MDCX) NACK | -> | Sent .3+.| <> | <> | RSL Delete Connection (DLCX) | <- | Received | <> | RSL Delete Connection (DLCX) ACK | -> | Sent | <> | RSL Delete Connection (DLCX) NACK | -> | Sent | <> | <> | RSL Delete Connection (DLCX) Indication | -> | Sent 5+<| *IPA style PDCH Management* (<>) .3+.| <> | <> | RSL PDCH Activation | <- | Received | <> | RSL PDCH Activation ACK | -> | Sent | <> | RSL PDCH Activation NACK | -> | Sent .3+.| <> | <> | RSL PDCH Deactivation | <- | Received | <> | RSL PDCH Deactivation ACK | -> | Sent | <> | RSL PDCH Deactivation NACK | -> | Sent 5+<| *COMMON CHANNEL MANAGEMENT MESSAGES* .3+.| <> | <> | 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 <>. NOTE:: Do not confuse this with the IPA style _PDCH ACT_ type dynamic PDCH protocol employed by nanoBTS devices (<>). [[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 <> 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 <> 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_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_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_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-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' (<>) and 'PDCH DEACTIVATE' (<>) 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 <>, <>, <> [[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 <>, <>, <> ===== 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 <>, 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 <> 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Destination IP Address | <> | O | TV | 5 | Destination IP Port | <> | O | TV | 3 | IP Speech Mode | <> | O | TV | 2 | RTP Payload Type 2 | <> | O | TV | 2 | 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Connection Id | <> | M | TV | 3 | Source IP Address | <> | O | TV | 5 | Source IP Port | <> | O | TV | 3 | RTP Payload Type 2 | <> | 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Destination IP Address | <> | O | TV | 5 | Destination IP 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Connection Id | <> | O | TV | 3 | Destination IP Address | <> | O | TV | 5 | Destination IP Port | <> | O | TV | 3 | IP Speech Mode | <> | O | TV | 2 | RTP Payload Type 2 | <> | O | TV | 2 | 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Connection Id | <> | O | TV | 3 | Source IP Address | <> | C | TV | 5 | Source IP Port | <> | C | TV | 3 | RTP Payload Type 2 | <> | 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 | <> | 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Connection Id | <> | M | TV | 3 | Connection Id | <> | 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Connection 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Connection Id | <> | O | TV | 3 | Connection Statistics | <> | 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 | <> | M | V | 1 | Channel number | 48.058 9.3.1 | M | TV | 2 | Connection 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 | <> | 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 | <> | 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 | <> | 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 | <> | 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 | <> | 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 | <> | 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 | <> | 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) | <> | 0x71 | Create Connection (CRCX) ACK | <> | 0x72 | Create Connection (CRCX) NACK | <> | 0x73 | Modify Connection (MDCX) | <> | 0x74 | Modify Connection (MDCX) ACK | <> | 0x75 | Modify Connection (MDCX) NACK | <> | 0x76 | Delete Connection (DLCX) Indication | <> | 0x77 | Delete Connection (DLCX) | <> | 0x78 | Delete Connection (DLCX) ACK | <> | 0x79 | Delete Connection (DLCX) NACK | <> | 0x7f | Osmocom ETWS Command | <> | 0x48 | PDCH Activate | <> | 0x49 | PDCH Activate ACK | <> | 0x4a | PDCH Activate NACK | <> | 0x4b | PDCH Deactivate | <> | 0x4c | PDCH Deactivate ACK | <> | 0x4d | PDCH Deactivate 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 | <> | 0x60 | RSL_IE_OSMO_REP_ACCH_CAP | <> | 0x61 | RSL_IE_OSMO_TRAINING_SEQUENCE | <> | 0x62 | RSL_IE_OSMO_TEMP_OVP_ACCH_CAP | <> | 0x63 | RSL_IE_OSMO_OSMUX_CID | <> | 0xf0 | RSL_IE_IPAC_REMOTE_IP | <> | 0xf1 | RSL_IE_IPAC_REMOTE_PORT | <> | 0xf3 | RSL_IE_IPAC_LOCAL_PORT | <> | 0xf4 | RSL_IE_IPAC_SPEECH_MODE | <> | 0xf5 | RSL_IE_IPAC_LOCAL_IP | <> | 0xf6 | RSL_IE_IPAC_CONN_STAT | <> | 0xf8 | RSL_IE_IPAC_CONN_ID | <> | 0xf9 | RSL_IE_IPAC_RTP_CSD_FORMAT | <> | 0xfc | 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 <>). 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]] .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_OSMO_TEMP_OVP_ACCH_CAP]] ==== RSL_IE_OSMO_TEMP_OVP_ACCH_CAP FIXME: this IE has been defined, but remains to be documented. [[RSL_IE_OSMO_OSMUX_CID]] ==== RSL_IE_OSMO_OSMUX_CID FIXME: this IE has been defined, but remains to be documented. [[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 <> and <>. Since the secondary TRX has no BCCH, it does not (need to) receive any 'RSL BCCH INFORMATION' messages from the BSC.