Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 1 | == Configuring OsmoPCU |
| 2 | |
| 3 | Contrary to other network elements (like OsmoBSC, OsmoNITB), the |
| 4 | OsmoPCU has a relatively simple minimum configuration. |
| 5 | |
| 6 | This is primarily because most of the PCU configuration happens |
| 7 | indirectly from the BSC, who passes the configuation over A-bis OML via |
| 8 | OsmoBTS and its PCU socket into OsmoPCU. |
| 9 | |
| 10 | A minimal OsmoPCU configuration file is provided below for your reference: |
| 11 | |
| 12 | .Example: Minimal OsmoPCU configuration file (`osmo-pcu.cfg`) |
| 13 | ---- |
| 14 | pcu |
| 15 | flow-control-interval 10 <1> |
| 16 | cs 2 <2> |
| 17 | alloc-algorithm dynamic <3> |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 18 | gamma 0 |
| 19 | ---- |
| 20 | <1> send a BSSGP flow-control PDU every 10 seconds |
| 21 | <2> start a TBF with the initial coding scheme 2 |
| 22 | <3> dynamically chose between single-slot or multi-slot TBF allocations |
| 23 | depending on system load |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 24 | |
| 25 | However, there are plenty of tuning parameters for people interested to |
| 26 | optimize PCU throughput or latency according to their requirements. |
| 27 | |
| 28 | === Configuring the Coding Schemes and Rate Adaption |
| 29 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 30 | As a reminder: |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 31 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 32 | - GPRS supports Coding Schemes 1-4 (CS1-4), all of them use GMSK modulation |
| 33 | (same as GSM). |
| 34 | - EGPRS supports MCS1-9, where MCS1-4 is GMSK, and MCS5-9 use 8-PSK modulation. |
| 35 | |
| 36 | The range of Coding Schemes above only apply to RLCMAC data blocks; RLCMAC |
| 37 | control blocks are always transmitted with CS1 (GMSK). Hence, CS1 is always |
| 38 | supported and must be always permitted. |
| 39 | |
| 40 | The BSC includes a bit-mask of permitted [E]GPRS coding schemes as part of the |
| 41 | A-bis OML configuration, controlled by VTY `gprs mode (none|gprs|egprs)`. This |
| 42 | is passed from the BTS via the PCU socket into OsmoPCU, and the resulting set |
| 43 | can be further constrained by OsmoPCU VTY configuration. |
| 44 | |
| 45 | Some additional OsmoPCU parameters can be set as described below. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 46 | |
| 47 | ==== Initial Coding Scheme |
| 48 | |
| 49 | You can use the `cs <1-4> [<1-4>]` command at the `pcu` VTY config node |
| 50 | to set the initial GPRS coding scheme to be used. The optional second |
| 51 | value allows to specify a different initial coding scheme for uplink. |
| 52 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 53 | Similarly, `mcs <1-9> [<1-9>]` can be used to set up the initial EGPRS coding |
| 54 | scheme. |
| 55 | |
| 56 | [[max_cs_mcs]] |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 57 | ==== Maximum Coding Scheme |
| 58 | |
| 59 | You can use the `cs max <1-4> [<1-4>]` command at the `pcu` VTY config |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 60 | node to set the maximum GPRS coding scheme that should be used as part of the |
| 61 | rate adaption. The optional second value allows to specify a different maximum |
| 62 | coding scheme for uplink. |
| 63 | |
| 64 | Similarly, `mcs max <1-9> [<1-9>]` can be used to set up the maximum EGPRS |
| 65 | coding scheme. |
| 66 | |
| 67 | The actual Maximum Coding Scheme for each direction used at runtime is actually |
| 68 | the result of taking the maximum value from the permitted GPRS coding schemes |
| 69 | received by the BSC (or BTS) over PCUIF which is equal or lower tho the |
| 70 | configured value. |
| 71 | |
| 72 | Example: PCUIF announces permitted MCS bit-mask (`MCS1 MCS2 MCS3 MCS4`) and |
| 73 | OsmoPCU is configured `mcs max 6`, then the actual maximum MCS used at runtime |
| 74 | will be `MCS4`. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 75 | |
| 76 | ==== Rate Adaption Error Thresholds |
| 77 | |
| 78 | You can use the `cs threshold <0-100> <0-100>` command at the `pcu` VTY |
| 79 | config node to determine the upper and lower limit for the error rate |
| 80 | percentage to use in the rate adaption. If the upper threshold is |
| 81 | reached, a lower coding sheme is chosen, and if the lower threshold is |
| 82 | reached, a higher coding scheme is chosen. |
| 83 | |
| 84 | ==== Rate Adation Link Quality Thresholds |
| 85 | |
| 86 | You can use the `cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 |
| 87 | <0-35> <0-35> cs4 <0-35>` command at the `pcu` VTY config node to tune |
Jonathan Brielmaier | 58721eb | 2016-05-25 15:01:11 +0200 | [diff] [blame] | 88 | the link quality ranges for the respective coding schemes. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 89 | |
| 90 | ==== Data Size based CS downgrade Threshold |
| 91 | |
| 92 | You can use the `cs downgrade-threshold <1-10000>` command at the `pcu` |
| 93 | VTY config node to ask the PCU to down-grade the coding scheme if less |
| 94 | than the specified number of octets are left to be transmitted. |
| 95 | |
| 96 | === Miscellaneous Configuration / Tuning Parameters |
| 97 | |
| 98 | ==== Downlink TBF idle time |
| 99 | |
| 100 | After a down-link TBF is idle (all data in the current LLC downlink |
Philipp | 452b533 | 2017-01-18 12:39:56 +0100 | [diff] [blame] | 101 | queue for the MS has been transmitted), we can keep the TBF established |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 102 | for a configurable time. This avoids having to go through a new one or |
| 103 | two phase TBF establishment once the next data for downlink arrives. |
| 104 | |
| 105 | You can use the `dl-tbf-idle-time <1-5000>` to specify that time in |
| 106 | units of milli-seconds. The default is 2 seconds. |
| 107 | |
| 108 | ==== MS idle time |
| 109 | |
| 110 | Using the `ms-idle-time <1-7200>` command at the `pcu` VTY config node |
| 111 | you can configure the number of seconds for which the PCU should keep |
| 112 | the MS data structure alive before releasing it if there are no active |
| 113 | TBF for this MS. |
| 114 | |
| 115 | The OsmoPCU default value is 60 seconds, which is slightly more than |
| 116 | what 3GPP TS 24.008 recommends for T3314 (44s). |
| 117 | |
| 118 | The MS data structure only consumes memory in the PCU and does not |
| 119 | require any resources of the air interface. |
| 120 | |
| 121 | ==== Forcing two-phase access |
| 122 | |
Philipp | 452b533 | 2017-01-18 12:39:56 +0100 | [diff] [blame] | 123 | If the MS is using a single-phase access, you can still force it to |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 124 | use a two-phase access using the `two-phase-access` VTY configuration |
| 125 | command at the `pcu` VTY config node. |
| 126 | |
| 127 | === Configuring BSSGP flow control |
| 128 | |
| 129 | BSSGP between SGSN and PCU contains a two-level nested flow control |
| 130 | mechanism: |
| 131 | |
| 132 | . one global flow control instance for the overall (downlink) traffic |
| 133 | from the SGSN to this PCU |
| 134 | . a per-MS flow control instance for each individual MS served by this |
| 135 | PCU |
| 136 | |
| 137 | Each of the flow control instance is implemented as a TBF (token bucket |
| 138 | filter). |
| 139 | |
| 140 | ==== Normal BSSGP Flow Control Tuning parameters |
| 141 | |
| 142 | You can use the following commands at the `pcu` VTY config node to tune |
Jonathan Brielmaier | 58721eb | 2016-05-25 15:01:11 +0200 | [diff] [blame] | 143 | the BSSGP flow control parameters: |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 144 | |
| 145 | `flow-control-interval <1-10>`:: |
| 146 | configure the interval (in seconds) between subsequent flow |
| 147 | control PDUs from PCU to SGSN |
| 148 | `flow-control bucket-time <1-65534>`:: |
| 149 | set the target downlink maximum queueing time in centi-seconds. |
| 150 | The PCU will attempt to adjust the advertised bucket size to match this |
| 151 | target. |
| 152 | |
| 153 | ==== Extended BSSGP Flow Control Tuning parameters |
| 154 | |
| 155 | There are some extended flow control related parameters at the `pcu` VTY |
| 156 | config node that override the automatic flow control as specified in the |
| 157 | BSSGP specification. Use them with care! |
| 158 | |
| 159 | `flow-control force-bvc-bucket-size <1-6553500>`:: |
| 160 | force the BVC (global) bucket size to the given number of octets |
| 161 | `flow-control force-bvc-leak-rate <1-6553500>`:: |
| 162 | force the BVC (global) bucket leak rate to the given number of bits/s |
| 163 | `flow-control force-ms-bucket-size <1-6553500>`:: |
| 164 | force the per-MS bucket size to the given number of octets |
| 165 | `flow-control force-ms-leak-rate <1-6553500>`:: |
| 166 | force the per-MS bucket leak rate to the given number of bits/s |
| 167 | |
| 168 | |
| 169 | === Configuring LLC queue |
| 170 | |
| 171 | The downlink LLC queue in the PCU towards the MS can be tuned with a |
| 172 | variety of parameters at the `pcu` VTY config node, depending on your |
| 173 | needs. |
| 174 | |
| 175 | `queue lifetime <1-65534>`:: |
| 176 | Each downlink LLC PDU is assigned a lifetime by the SGSN, which |
| 177 | is respected by the PDU *unless* you use this command to |
| 178 | override the PDU lifetime with a larger value (in centi-seconds) |
| 179 | `queue lifetime infinite`:: |
| 180 | Never drop LLC PDUs, i.e. give them an unlimited lifetime. |
| 181 | `queue hysteresis <1-65535>`:: |
| 182 | When the downlink LLC queue is full, the PCU starts dropping |
| 183 | packets. Using this parameter, we can set the lifetime |
| 184 | hysteresis in centi-seconds, i.e. it will continue discarding |
| 185 | until "lifetime - hysteresis" is reached. |
| 186 | `queue codel`:: |
| 187 | Use the 'CoDel' (Controlled Delay) scheduling algorithm, which |
| 188 | is designed to overcome buffer bloat. It will use a default |
| 189 | interval of 4 seconds. |
| 190 | `queue codel interval <1-1000>`:: |
| 191 | Use the 'CoDel' (Controlled Delay) scheduling algorithm, which |
| 192 | is designed to overcome buffer bloat. Use the specified |
| 193 | interval in centi-seconds. |
| 194 | `queue idle-ack-delay <1-65535>`:: |
| 195 | Delay the request for an ACK after the last downlink LLC frame |
| 196 | by the specified amount of centi-seconds. |
| 197 | |
| 198 | |
| 199 | === Configuring MS power control |
| 200 | |
| 201 | GPRS MS power control works completely different than the close MS power |
| 202 | control loop in circuit-switched GSM. |
| 203 | |
| 204 | Rather than instructing the MS constantly about which transmit power to |
| 205 | use, some parameters are provided to the MS by which the MS-based power |
| 206 | control algorithm is tuned. |
| 207 | |
| 208 | See 3GPP TS 05.08 for further information on the algorithm and the |
| 209 | parameters. |
| 210 | |
| 211 | You can set those parameters at the `pcu` VTY config node as follows: |
| 212 | |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 213 | `gamma <0-62>`:: |
| 214 | Set the gamma parameter for MS power control in units of dB. |
| 215 | |
Pau Espin Pedrol | fe8de45 | 2021-02-09 18:47:34 +0100 | [diff] [blame] | 216 | Parameter `ALPHA` is set on the BSC VTY configuration file on a per-BTS basis, |
| 217 | and forwarded by OsmoPCU to the MS through the SI13 received from the former |
| 218 | over PCUIF. OsmoPCU VTY command `alpha <0-10>` overrides the value received over |
| 219 | PCUIF to keep backward compatibility with existing config files, but it is |
| 220 | currently deprecated and its use is discouraged; one should configure it per-BTS |
| 221 | in OsmoBSC VTY instead. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 222 | |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 223 | === Configuring Network Assisted Cell Change (NACC) |
| 224 | |
| 225 | Network Assisted Cell Change, defined in 3GPP TS 44.060 sub-clause 8.8, is a |
| 226 | feature providing the MS aid when changing to a new cell due to autonomous |
| 227 | reselection. In summary, the MS informs the current cell its intention to change |
| 228 | to a new target cell, and the network decides whether to grant the intended cell |
| 229 | change or order a change to another neighbor cell. It also provides several |
| 230 | System Informations of the target cell to the MS to allow for quicker |
| 231 | reselection towards it. |
| 232 | |
| 233 | OsmoPCU will automatically provide the required neighbor System Information when |
| 234 | the MS requests NACC towards a target cell also under the management of the same |
| 235 | OsmoPCU instance, since it already has the System Information of all BTS under |
| 236 | their control, obtained through PCUIF when the BTS registers against OsmoPCU, so |
| 237 | no specific user configuration is required here. |
| 238 | |
Pau Espin Pedrol | 44768f2 | 2021-02-02 13:11:30 +0100 | [diff] [blame] | 239 | In general, OsmoPCU requires to gather the information from somewhere else |
| 240 | before being able to provide it to the MS requesting the NACC. |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 241 | |
| 242 | If OsmoPCU fails to gather the System Information, it will simply answer the MS |
| 243 | allowing the proposed changed but without previously providing the System |
| 244 | Information of the target cell. |
| 245 | |
| 246 | ==== Neighbor Address Resolution |
| 247 | |
| 248 | First of all, it needs to translate the <ARFCN + BSIC> identity of the target |
| 249 | cell to change to, provided by the MS, into an identity that the Core Network |
| 250 | can use and understand to identify the target cell, which happens to be a key |
| 251 | composed of <RAI + Cell Identity>. This key is also named conveniently as |
| 252 | CGI-PS, since it actually equals to the Circuit Switch CGI + RAC. |
| 253 | |
| 254 | In order to apply this target cell identity translation, OsmoPCU uses the |
Pau Espin Pedrol | 5557c0a | 2021-09-07 14:09:50 +0200 | [diff] [blame] | 255 | OsmoBSC Neighbor Resolution Service. This service is nowadays provided by means |
| 256 | of PCUIF container messages, which are transparently forwarded in both directions |
| 257 | by the BTS using the IPA multiplex of the OML connection against the BSC. No |
| 258 | specific configuration is required in any of the involved nodes, they should |
| 259 | behave properly out of the box. |
| 260 | |
| 261 | These neighbor address resolutions (<ARFCN + BSIC> => <RAI + CI>) are by default |
| 262 | cached for a while, in order to avoid querying the BSC frequently. As a result, |
| 263 | the resolution time is also optimized. |
| 264 | |
| 265 | .Example: Configure Neighbor Resolution cache and timeouts |
| 266 | ---- |
| 267 | pcu |
| 268 | timer X1 500 <1> |
| 269 | timer X0 60 <2> |
| 270 | ---- |
| 271 | <1> Time out if the BSC doesn't answer our resolution request after 500 ms |
| 272 | <2> Keep resolved neighbor addresses cached for 60 seconds |
| 273 | |
| 274 | ===== OsmoBSC CTRL interface (deprecated) |
| 275 | |
| 276 | CAUTION: This interface is nowadays considered deprecated and should not be used |
| 277 | anymore. Any related VTY options should be dropped from configuration files, to |
| 278 | let OsmoPCU use the new interface instead. This section is kept here for a while |
| 279 | as a reference for old deployments using old versions of the programs. |
| 280 | |
| 281 | This Neighbor Address Resolution Service was initially implemented by means of a |
| 282 | separate CTRL interface (see OsmoBSC User Manual), where OsmoPCU would create a |
| 283 | CTRL connection to the BSC each time an address resolution was required. |
| 284 | |
| 285 | Older versions of OsmoBSC may not support the current Neighbor Address |
| 286 | Resolution Service over the IPA multiplex (see above). For those cases, OsmoPCU |
| 287 | can be configured to use the old deprecated CTRL interface. |
| 288 | |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 289 | By default, the use of this interface is not configured and hence disabled in |
| 290 | OsmoPCU. As a result, until configured, the network won't be able to provide the |
| 291 | System Information to the MS prior to allowing the change during NACC against |
| 292 | remote cells, which means the cell change will take longer to complete. In order |
| 293 | to configure the interface, the OsmoBSC IP address and port to connect to must |
| 294 | be configured in OsmoPCU VTY. |
| 295 | |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 296 | .Example: Configure Neighbor Resolution CTRL interface against OsmoBSC |
| 297 | ---- |
| 298 | pcu |
| 299 | neighbor resolution 172.18.13.10 4248 <1> |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 300 | ---- |
| 301 | <1> Port 4248 is the default and hence could be omitted in this case |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 302 | |
| 303 | ==== System Information Resolution |
| 304 | |
| 305 | Once OsmoPCU gains knowledge of the target cell's address in the Core Network, |
Pau Espin Pedrol | 44768f2 | 2021-02-02 13:11:30 +0100 | [diff] [blame] | 306 | it can query its System Information. |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 307 | |
Pau Espin Pedrol | 44768f2 | 2021-02-02 13:11:30 +0100 | [diff] [blame] | 308 | OsmoPCU will gather the requested System Information of target cells under its |
| 309 | control without need for any external query, since the System Information of all |
| 310 | BTSs it manages are received over PCUIF and stored internally in OsmoPCU. |
| 311 | |
| 312 | For those targets cells not managed by the OsmoPCU instance, the query is |
| 313 | accomplished by using RIM procedures (NACC RAN-INFO application) over the Gb |
| 314 | interface against the SGSN that OsmoPCU is connected to. In its turn, the SGSN |
| 315 | will potentially forward this query to the PCU serving the target cell, which |
| 316 | will provide back the System Information of that cell. |
| 317 | |
| 318 | The System Information received from external PCUs over RIM are by default |
Pau Espin Pedrol | ced5c1f | 2021-01-29 15:52:44 +0100 | [diff] [blame] | 319 | cached for a while in order to avoid querying the SGSN frequently and, as a |
| 320 | result, optimizing the resolution time too. |
| 321 | |
| 322 | .Example: Configure System Information resolution |
| 323 | ---- |
| 324 | pcu |
| 325 | timer X2 500 <1> |
| 326 | timer X11 60 <2> |
| 327 | ---- |
| 328 | <1> Time out if the SGSN doesn't answer our RIM RAN-INFO request request after 500 ms |
| 329 | <2> Keep resolved remote neighbor System Information cached for 60 seconds |
| 330 | |
| 331 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 332 | === GPRS vs EGPRS considerations |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 333 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 334 | ==== Configuration |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 335 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 336 | OsmoPCU can be configured to either: |
| 337 | |
| 338 | - Allocate only GPRS TBFs to all MS (no EGPRS) |
| 339 | - Allocate EGPRS TBFs to EGPRS capable phones while still falling back to |
| 340 | allocating GPRS TBFs on GPRS-only capable MS. |
| 341 | |
| 342 | These two different modes of operation are selected by properly configuring the |
| 343 | Coding Schemes (see <<max_cs_mcs>>). |
| 344 | |
| 345 | The first mode of operation (GPRS-only for all MS) can be accomplished |
| 346 | configuring OsmoPCU so that the resulting MCS set is empty. This can be done in |
| 347 | two ways: |
| 348 | |
| 349 | - Announcing an empty MCS bit-mask over PCUIF to OsmoPCU: |
| 350 | That's actually done automatically by OsmoBSC on BTS with VTY config set to |
| 351 | `gprs mode gprs`. |
| 352 | - Configuring OsmoPCU to force an empty set by using VTY command `mcs max 0`. |
| 353 | |
| 354 | Hence, if the resulting MCS bit-mask is not empty, (BSC configuring the BTS with |
| 355 | `gprs mode egprs` and OsmoPCU VTY containing something other than 'mcs max 0'), |
| 356 | EGPRS TBFs will be allocated for all MS announcing EGPRS capabilities. |
| 357 | |
| 358 | It is important to remark that in order to use MCS5-9, the BTS must support |
| 359 | 8-PSK modulation. Nevertheless, in case 8-PSK is not supported by the BTS, one |
| 360 | can still enable EGPRS and simply make sure 8-PSK MCS are never used by |
| 361 | configuring OsmoPCU with `mcs max 4 4`. |
| 362 | |
| 363 | Similarly, a BTS may support 8-PSK modulation only on downlink, since it is |
| 364 | easier to implement than the uplink, together with the fact that higher downlink |
| 365 | throughput is usually more interesting from user point of view. In this |
| 366 | scenario, OsmoPCU can be configured to allow for full MCS range in downlink |
| 367 | while still preventing use of 8-PSK on the uplink: `mcs max 9 4`. |
| 368 | |
| 369 | Some other interesting configurations to control use of EGPRS in the network |
| 370 | which lay outside OsmoPCU include: |
| 371 | |
| 372 | - If `osmo-bts-trx` together with `osmo-trx` is used, remember to enable EGPRS |
| 373 | support (OsmoTRX VTY `egprs enable`). |
| 374 | |
| 375 | - It is possible to improve EGPRS performance (in particular, the TBF |
| 376 | establishment timing) a bit by enabling 11-bit Access Burst support. This |
| 377 | allows EGPRS capable phones to indicate their EGPRS capability, establishment |
| 378 | cause, and multi-slot class directly in the Access Burst (OsmoTRX VTY |
| 379 | `ext-rach enable`, OsmoBSC VTY `gprs egprs-packet-channel-request`). |
| 380 | |
| 381 | NOTE: If you enable MCS5-9 you will also need an 8-PSK capable OsmoBTS+PHY, |
| 382 | which means `osmo-bts-sysmo` or `osmo-bts-litecell15` with their associated PHY, |
| 383 | or `osmo-bts-trx` with `osmo-trx` properly configured. |
| 384 | |
| 385 | ==== GPRS+EGPRS multiplexing |
| 386 | |
| 387 | Both EGPRS and GPRS-only capable MS can be driven concurrently in the same PDCH |
| 388 | timeslot by the PCU, hence no special configuration is required per timeslot |
| 389 | regarding this topic; OsmoPCU scheduler takes care of the specific requirements |
| 390 | when driving MS with different capabilities. |
| 391 | |
| 392 | These specific requirements translate to some restrictions regarding which |
| 393 | Coding Schemes can be used at given frame numbers, and hence which kind of |
| 394 | RLCMAC blocks can be sent, which means serving a GPRS-only MS in a PDCH may end |
| 395 | up affecting slightly the downlink throughput of EGPRS capable MS. |
| 396 | |
| 397 | Throughput loss based on MS capabilities with TBF attached to a certain PDCH |
| 398 | timeslot: |
| 399 | |
| 400 | All UEs are EGPRS capable:: |
| 401 | No throughput loss, since all data is sent using EGPRS, and EGPRS control |
| 402 | messages are used when appropriate. |
| 403 | |
| 404 | All UEs are GPRS-only (doesn't support EGPRS):: |
| 405 | No throughput loss, since all data and control blocks use GPRS. |
| 406 | |
| 407 | Some UEs are GPRS-only, some EGPRS:: |
| 408 | In general EGPRS capable UEs will use EGPRS, and GPRS-only UEs will use GPRS, |
| 409 | with some restrictions affecting throughput of EGPRS capable UEs: |
| 410 | - Whenever a GPRS-only MS is to be polled to send uplink data to PCU, then a |
| 411 | downlink RLCMAC block modulated using GMSK must be sent, which means that if the |
| 412 | scheduler selects a EGPRS MS for downlink on that block it will force sending of |
| 413 | data with MCS1-4 (if it's new data, if it's a retransmission it cannot be |
| 414 | selected since MCS from original message cannot be changed). In the worst case |
| 415 | if no control block needs to be sent or no new data in MCS1-4 is available to |
| 416 | send, then an RLCMAC Dummy Block is sent. |
| 417 | - For synchronization purposes, each MS needs to receive an RLCMAC block which |
| 418 | it can fully decode at least every 360ms, which means the scheduler must enforce |
| 419 | a downlink block in CS1-4 every 360ms, that is, every 18th RLCMAC block. In |
| 420 | general this is not a big issue since anyway all control RLCMAC blocks are |
| 421 | encoded in CS1, so in case any control block is sent from time to time it's |
| 422 | accomplished and there's no penalty. However, if only EGPRS downlink data is sent |
| 423 | over that time frame, then the scheduler will force sending a RLCMAC Dummy |
| 424 | Block. |
Pau Espin Pedrol | 13866f0 | 2021-11-12 13:42:03 +0100 | [diff] [blame] | 425 | |
| 426 | [[gsmtap]] |
| 427 | === Configuring GSMTAP tracing |
| 428 | |
| 429 | In addition to being able to obtain pcap protocol traces of the NS/BSSGP |
| 430 | communication and the text-based logging from the OsmoPCU software, there is |
| 431 | also the capability of tracing all communication on the radio interface related |
| 432 | to PS. To do so, OsmoPCU can encapsulate MAC blocks (23-155 byte messages at the |
| 433 | L2-L1 interface depending on coding scheme) into _GSMTAP_ and send them via |
| 434 | UDP/IP. At that point, they can be captured with utilities like *tcpdump* or |
| 435 | *tshark* for further analysis by the *wireshark* protocol analyzer. |
| 436 | |
| 437 | In order to activate this feature, you first need to make sure to specify |
| 438 | the remote address of _GSMTAP_ host in the configuration file. In most |
| 439 | cases, using 127.0.0.1 for passing the messages over the loopback (`lo`) |
| 440 | device will be sufficient: |
| 441 | |
| 442 | .Example: Enabling GSMTAP Um-frame logging to localhost |
| 443 | ---- |
| 444 | pcu |
| 445 | gsmtap-remote-host 127.0.0.1 <1> |
| 446 | ---- |
| 447 | <1> Destination address for _GSMTAP_ Um-frames |
| 448 | |
| 449 | NOTE: Changing this parameter at run-time will not affect the existing |
| 450 | _GSMTAP_ connection, full program restart is required. |
| 451 | |
| 452 | NOTE: Command line parameters `-i` and `--gsmtap-ip` have been deprecated. |
| 453 | |
| 454 | OsmoPCU can selectively trace such messages based on different categories, for |
| 455 | both Ul and Dl. For a complete list of cateogry values, please refer to the |
| 456 | _OsmoPCU VTY reference manual_ <<vty-ref-osmopcu>>. |
| 457 | |
| 458 | For example, to enable GSMTAP tracing for all DL EGPRS rlcmac data blocks, you |
| 459 | can use the `gsmtap-category dl-data-egprs` command at the `pcu` node of the |
| 460 | OsmoPCU VTY. |
| 461 | |
| 462 | .Example: Enabling GSMTAP for for all DL EGPRS rlcmac data blocks |
| 463 | ---- |
| 464 | OsmoPCU> enable |
| 465 | OsmoPCU# configure terminal |
| 466 | OsmoPCU(config)# pcu |
| 467 | OsmoPCU(pcu)# gsmtap-category dl-data-egprs |
| 468 | OsmoPCU(trx)# write <1> |
| 469 | ---- |
| 470 | <1> the `write` command will make the configuration persistent in the |
| 471 | configuration file. This is not required if you wish to enable GSMTAP |
| 472 | only in the current session of OsmoPCU. |
| 473 | |
| 474 | De-activation can be performed similarly by using the `no gsmtap-category |
| 475 | dl-data-egprs` command at the `pcu` node of the OsmoPCU VTY. |
| 476 | |
| 477 | It may be useful to enable all categories with a few exceptions, or vice versa |
| 478 | disable everything using one command. For this purpose, the VTY provides |
| 479 | `gsmtap-category enable-all` and `gsmtap-category disable-all` commands. |
| 480 | |
| 481 | .Example: Enabling all categoriess except _dl-dummy_ |
| 482 | ---- |
| 483 | pcu |
| 484 | gsmtap-category enable-all <1> |
| 485 | no gsmtap-category dl-dummy <2> |
| 486 | ---- |
| 487 | <1> Enable all available SAPIs |
| 488 | <2> Exclude DL RLCMAC blocks |
| 489 | |
| 490 | From the moment they are enabled via VTY, GSMTAP messages will be |
| 491 | generated and sent in UDP encapsulation to the IANA-registered UDP port |
| 492 | for GSMTAP (4729) of the specified remote address. |