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> |
| 18 | alpha 0 <4> |
| 19 | gamma 0 |
| 20 | ---- |
| 21 | <1> send a BSSGP flow-control PDU every 10 seconds |
| 22 | <2> start a TBF with the initial coding scheme 2 |
| 23 | <3> dynamically chose between single-slot or multi-slot TBF allocations |
| 24 | depending on system load |
| 25 | <4> disable MS power control loop |
| 26 | |
| 27 | However, there are plenty of tuning parameters for people interested to |
| 28 | optimize PCU throughput or latency according to their requirements. |
| 29 | |
| 30 | === Configuring the Coding Schemes and Rate Adaption |
| 31 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 32 | As a reminder: |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 33 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 34 | - GPRS supports Coding Schemes 1-4 (CS1-4), all of them use GMSK modulation |
| 35 | (same as GSM). |
| 36 | - EGPRS supports MCS1-9, where MCS1-4 is GMSK, and MCS5-9 use 8-PSK modulation. |
| 37 | |
| 38 | The range of Coding Schemes above only apply to RLCMAC data blocks; RLCMAC |
| 39 | control blocks are always transmitted with CS1 (GMSK). Hence, CS1 is always |
| 40 | supported and must be always permitted. |
| 41 | |
| 42 | The BSC includes a bit-mask of permitted [E]GPRS coding schemes as part of the |
| 43 | A-bis OML configuration, controlled by VTY `gprs mode (none|gprs|egprs)`. This |
| 44 | is passed from the BTS via the PCU socket into OsmoPCU, and the resulting set |
| 45 | can be further constrained by OsmoPCU VTY configuration. |
| 46 | |
| 47 | Some additional OsmoPCU parameters can be set as described below. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 48 | |
| 49 | ==== Initial Coding Scheme |
| 50 | |
| 51 | You can use the `cs <1-4> [<1-4>]` command at the `pcu` VTY config node |
| 52 | to set the initial GPRS coding scheme to be used. The optional second |
| 53 | value allows to specify a different initial coding scheme for uplink. |
| 54 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 55 | Similarly, `mcs <1-9> [<1-9>]` can be used to set up the initial EGPRS coding |
| 56 | scheme. |
| 57 | |
| 58 | [[max_cs_mcs]] |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 59 | ==== Maximum Coding Scheme |
| 60 | |
| 61 | 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] | 62 | node to set the maximum GPRS coding scheme that should be used as part of the |
| 63 | rate adaption. The optional second value allows to specify a different maximum |
| 64 | coding scheme for uplink. |
| 65 | |
| 66 | Similarly, `mcs max <1-9> [<1-9>]` can be used to set up the maximum EGPRS |
| 67 | coding scheme. |
| 68 | |
| 69 | The actual Maximum Coding Scheme for each direction used at runtime is actually |
| 70 | the result of taking the maximum value from the permitted GPRS coding schemes |
| 71 | received by the BSC (or BTS) over PCUIF which is equal or lower tho the |
| 72 | configured value. |
| 73 | |
| 74 | Example: PCUIF announces permitted MCS bit-mask (`MCS1 MCS2 MCS3 MCS4`) and |
| 75 | OsmoPCU is configured `mcs max 6`, then the actual maximum MCS used at runtime |
| 76 | will be `MCS4`. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 77 | |
| 78 | ==== Rate Adaption Error Thresholds |
| 79 | |
| 80 | You can use the `cs threshold <0-100> <0-100>` command at the `pcu` VTY |
| 81 | config node to determine the upper and lower limit for the error rate |
| 82 | percentage to use in the rate adaption. If the upper threshold is |
| 83 | reached, a lower coding sheme is chosen, and if the lower threshold is |
| 84 | reached, a higher coding scheme is chosen. |
| 85 | |
| 86 | ==== Rate Adation Link Quality Thresholds |
| 87 | |
| 88 | You can use the `cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 |
| 89 | <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] | 90 | the link quality ranges for the respective coding schemes. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 91 | |
| 92 | ==== Data Size based CS downgrade Threshold |
| 93 | |
| 94 | You can use the `cs downgrade-threshold <1-10000>` command at the `pcu` |
| 95 | VTY config node to ask the PCU to down-grade the coding scheme if less |
| 96 | than the specified number of octets are left to be transmitted. |
| 97 | |
| 98 | === Miscellaneous Configuration / Tuning Parameters |
| 99 | |
| 100 | ==== Downlink TBF idle time |
| 101 | |
| 102 | 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] | 103 | 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] | 104 | for a configurable time. This avoids having to go through a new one or |
| 105 | two phase TBF establishment once the next data for downlink arrives. |
| 106 | |
| 107 | You can use the `dl-tbf-idle-time <1-5000>` to specify that time in |
| 108 | units of milli-seconds. The default is 2 seconds. |
| 109 | |
| 110 | ==== MS idle time |
| 111 | |
| 112 | Using the `ms-idle-time <1-7200>` command at the `pcu` VTY config node |
| 113 | you can configure the number of seconds for which the PCU should keep |
| 114 | the MS data structure alive before releasing it if there are no active |
| 115 | TBF for this MS. |
| 116 | |
| 117 | The OsmoPCU default value is 60 seconds, which is slightly more than |
| 118 | what 3GPP TS 24.008 recommends for T3314 (44s). |
| 119 | |
| 120 | The MS data structure only consumes memory in the PCU and does not |
| 121 | require any resources of the air interface. |
| 122 | |
| 123 | ==== Forcing two-phase access |
| 124 | |
Philipp | 452b533 | 2017-01-18 12:39:56 +0100 | [diff] [blame] | 125 | 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] | 126 | use a two-phase access using the `two-phase-access` VTY configuration |
| 127 | command at the `pcu` VTY config node. |
| 128 | |
| 129 | === Configuring BSSGP flow control |
| 130 | |
| 131 | BSSGP between SGSN and PCU contains a two-level nested flow control |
| 132 | mechanism: |
| 133 | |
| 134 | . one global flow control instance for the overall (downlink) traffic |
| 135 | from the SGSN to this PCU |
| 136 | . a per-MS flow control instance for each individual MS served by this |
| 137 | PCU |
| 138 | |
| 139 | Each of the flow control instance is implemented as a TBF (token bucket |
| 140 | filter). |
| 141 | |
| 142 | ==== Normal BSSGP Flow Control Tuning parameters |
| 143 | |
| 144 | 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] | 145 | the BSSGP flow control parameters: |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 146 | |
| 147 | `flow-control-interval <1-10>`:: |
| 148 | configure the interval (in seconds) between subsequent flow |
| 149 | control PDUs from PCU to SGSN |
| 150 | `flow-control bucket-time <1-65534>`:: |
| 151 | set the target downlink maximum queueing time in centi-seconds. |
| 152 | The PCU will attempt to adjust the advertised bucket size to match this |
| 153 | target. |
| 154 | |
| 155 | ==== Extended BSSGP Flow Control Tuning parameters |
| 156 | |
| 157 | There are some extended flow control related parameters at the `pcu` VTY |
| 158 | config node that override the automatic flow control as specified in the |
| 159 | BSSGP specification. Use them with care! |
| 160 | |
| 161 | `flow-control force-bvc-bucket-size <1-6553500>`:: |
| 162 | force the BVC (global) bucket size to the given number of octets |
| 163 | `flow-control force-bvc-leak-rate <1-6553500>`:: |
| 164 | force the BVC (global) bucket leak rate to the given number of bits/s |
| 165 | `flow-control force-ms-bucket-size <1-6553500>`:: |
| 166 | force the per-MS bucket size to the given number of octets |
| 167 | `flow-control force-ms-leak-rate <1-6553500>`:: |
| 168 | force the per-MS bucket leak rate to the given number of bits/s |
| 169 | |
| 170 | |
| 171 | === Configuring LLC queue |
| 172 | |
| 173 | The downlink LLC queue in the PCU towards the MS can be tuned with a |
| 174 | variety of parameters at the `pcu` VTY config node, depending on your |
| 175 | needs. |
| 176 | |
| 177 | `queue lifetime <1-65534>`:: |
| 178 | Each downlink LLC PDU is assigned a lifetime by the SGSN, which |
| 179 | is respected by the PDU *unless* you use this command to |
| 180 | override the PDU lifetime with a larger value (in centi-seconds) |
| 181 | `queue lifetime infinite`:: |
| 182 | Never drop LLC PDUs, i.e. give them an unlimited lifetime. |
| 183 | `queue hysteresis <1-65535>`:: |
| 184 | When the downlink LLC queue is full, the PCU starts dropping |
| 185 | packets. Using this parameter, we can set the lifetime |
| 186 | hysteresis in centi-seconds, i.e. it will continue discarding |
| 187 | until "lifetime - hysteresis" is reached. |
| 188 | `queue codel`:: |
| 189 | Use the 'CoDel' (Controlled Delay) scheduling algorithm, which |
| 190 | is designed to overcome buffer bloat. It will use a default |
| 191 | interval of 4 seconds. |
| 192 | `queue codel interval <1-1000>`:: |
| 193 | Use the 'CoDel' (Controlled Delay) scheduling algorithm, which |
| 194 | is designed to overcome buffer bloat. Use the specified |
| 195 | interval in centi-seconds. |
| 196 | `queue idle-ack-delay <1-65535>`:: |
| 197 | Delay the request for an ACK after the last downlink LLC frame |
| 198 | by the specified amount of centi-seconds. |
| 199 | |
| 200 | |
| 201 | === Configuring MS power control |
| 202 | |
| 203 | GPRS MS power control works completely different than the close MS power |
| 204 | control loop in circuit-switched GSM. |
| 205 | |
| 206 | Rather than instructing the MS constantly about which transmit power to |
| 207 | use, some parameters are provided to the MS by which the MS-based power |
| 208 | control algorithm is tuned. |
| 209 | |
| 210 | See 3GPP TS 05.08 for further information on the algorithm and the |
| 211 | parameters. |
| 212 | |
| 213 | You can set those parameters at the `pcu` VTY config node as follows: |
| 214 | |
| 215 | `alpha <0-10>`:: |
Jonathan Brielmaier | 58721eb | 2016-05-25 15:01:11 +0200 | [diff] [blame] | 216 | Alpha parameter for MS power control in units of 0.1. |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 217 | Make sure to set the alpha value at System Information 13 (in |
| 218 | the BSC), too! |
| 219 | `gamma <0-62>`:: |
| 220 | Set the gamma parameter for MS power control in units of dB. |
| 221 | |
| 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 | |
| 239 | However, for remote neighbors (cells managed by another OsmoPCU instance), |
| 240 | OsmoPCU requires to gather the information from somewhere else before being able |
| 241 | to provide it to the MS requesting the NACC. |
| 242 | |
| 243 | If OsmoPCU fails to gather the System Information, it will simply answer the MS |
| 244 | allowing the proposed changed but without previously providing the System |
| 245 | Information of the target cell. |
| 246 | |
| 247 | ==== Neighbor Address Resolution |
| 248 | |
| 249 | First of all, it needs to translate the <ARFCN + BSIC> identity of the target |
| 250 | cell to change to, provided by the MS, into an identity that the Core Network |
| 251 | can use and understand to identify the target cell, which happens to be a key |
| 252 | composed of <RAI + Cell Identity>. This key is also named conveniently as |
| 253 | CGI-PS, since it actually equals to the Circuit Switch CGI + RAC. |
| 254 | |
| 255 | In order to apply this target cell identity translation, OsmoPCU uses the |
| 256 | OsmoBSC Neighbor Resolution CTRL interface (see OsmoBSC User Manual), since the |
| 257 | BSC is the node holding all the neighbor related information. |
| 258 | By default, the use of this interface is not configured and hence disabled in |
| 259 | OsmoPCU. As a result, until configured, the network won't be able to provide the |
| 260 | System Information to the MS prior to allowing the change during NACC against |
| 261 | remote cells, which means the cell change will take longer to complete. In order |
| 262 | to configure the interface, the OsmoBSC IP address and port to connect to must |
| 263 | be configured in OsmoPCU VTY. |
| 264 | |
| 265 | These neighbor address resolutions (<ARFCN + BSIC> => <RAI + CI>) are by default |
| 266 | cached for a while in order to avoid querying the BSC frequently and, as a |
| 267 | result, optimizing the resolution time too. |
| 268 | |
| 269 | .Example: Configure Neighbor Resolution CTRL interface against OsmoBSC |
| 270 | ---- |
| 271 | pcu |
| 272 | neighbor resolution 172.18.13.10 4248 <1> |
| 273 | timer X1 500 <2> |
| 274 | timer X0 60 <3> |
| 275 | ---- |
| 276 | <1> Port 4248 is the default and hence could be omitted in this case |
| 277 | <2> Time out if the BSC doesn't answer our CTRL resolution request after 500 ms |
| 278 | <3> Keep resolved neighbor addresses cached for 60 seconds |
| 279 | |
| 280 | ==== System Information Resolution |
| 281 | |
| 282 | Once OsmoPCU gains knowledge of the target cell's address in the Core Network, |
| 283 | it can query its System Information. The query is done using RIM procedures |
| 284 | (NACC RAN-INFO application) over the Gb interface against the SGSN that OsmoPCU |
| 285 | is connected to. In its turn, the SGSN will potentially forward this query to |
| 286 | the PCU serving the target cell, which will provide back the System Information |
| 287 | of that cell. |
| 288 | |
| 289 | The System Information received from remote neighbors are by default |
| 290 | cached for a while in order to avoid querying the SGSN frequently and, as a |
| 291 | result, optimizing the resolution time too. |
| 292 | |
| 293 | .Example: Configure System Information resolution |
| 294 | ---- |
| 295 | pcu |
| 296 | timer X2 500 <1> |
| 297 | timer X11 60 <2> |
| 298 | ---- |
| 299 | <1> Time out if the SGSN doesn't answer our RIM RAN-INFO request request after 500 ms |
| 300 | <2> Keep resolved remote neighbor System Information cached for 60 seconds |
| 301 | |
| 302 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 303 | === GPRS vs EGPRS considerations |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 304 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 305 | ==== Configuration |
Harald Welte | 4ff37fe | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 306 | |
Pau Espin Pedrol | d3123ea | 2021-01-05 13:26:34 +0100 | [diff] [blame] | 307 | OsmoPCU can be configured to either: |
| 308 | |
| 309 | - Allocate only GPRS TBFs to all MS (no EGPRS) |
| 310 | - Allocate EGPRS TBFs to EGPRS capable phones while still falling back to |
| 311 | allocating GPRS TBFs on GPRS-only capable MS. |
| 312 | |
| 313 | These two different modes of operation are selected by properly configuring the |
| 314 | Coding Schemes (see <<max_cs_mcs>>). |
| 315 | |
| 316 | The first mode of operation (GPRS-only for all MS) can be accomplished |
| 317 | configuring OsmoPCU so that the resulting MCS set is empty. This can be done in |
| 318 | two ways: |
| 319 | |
| 320 | - Announcing an empty MCS bit-mask over PCUIF to OsmoPCU: |
| 321 | That's actually done automatically by OsmoBSC on BTS with VTY config set to |
| 322 | `gprs mode gprs`. |
| 323 | - Configuring OsmoPCU to force an empty set by using VTY command `mcs max 0`. |
| 324 | |
| 325 | Hence, if the resulting MCS bit-mask is not empty, (BSC configuring the BTS with |
| 326 | `gprs mode egprs` and OsmoPCU VTY containing something other than 'mcs max 0'), |
| 327 | EGPRS TBFs will be allocated for all MS announcing EGPRS capabilities. |
| 328 | |
| 329 | It is important to remark that in order to use MCS5-9, the BTS must support |
| 330 | 8-PSK modulation. Nevertheless, in case 8-PSK is not supported by the BTS, one |
| 331 | can still enable EGPRS and simply make sure 8-PSK MCS are never used by |
| 332 | configuring OsmoPCU with `mcs max 4 4`. |
| 333 | |
| 334 | Similarly, a BTS may support 8-PSK modulation only on downlink, since it is |
| 335 | easier to implement than the uplink, together with the fact that higher downlink |
| 336 | throughput is usually more interesting from user point of view. In this |
| 337 | scenario, OsmoPCU can be configured to allow for full MCS range in downlink |
| 338 | while still preventing use of 8-PSK on the uplink: `mcs max 9 4`. |
| 339 | |
| 340 | Some other interesting configurations to control use of EGPRS in the network |
| 341 | which lay outside OsmoPCU include: |
| 342 | |
| 343 | - If `osmo-bts-trx` together with `osmo-trx` is used, remember to enable EGPRS |
| 344 | support (OsmoTRX VTY `egprs enable`). |
| 345 | |
| 346 | - It is possible to improve EGPRS performance (in particular, the TBF |
| 347 | establishment timing) a bit by enabling 11-bit Access Burst support. This |
| 348 | allows EGPRS capable phones to indicate their EGPRS capability, establishment |
| 349 | cause, and multi-slot class directly in the Access Burst (OsmoTRX VTY |
| 350 | `ext-rach enable`, OsmoBSC VTY `gprs egprs-packet-channel-request`). |
| 351 | |
| 352 | NOTE: If you enable MCS5-9 you will also need an 8-PSK capable OsmoBTS+PHY, |
| 353 | which means `osmo-bts-sysmo` or `osmo-bts-litecell15` with their associated PHY, |
| 354 | or `osmo-bts-trx` with `osmo-trx` properly configured. |
| 355 | |
| 356 | ==== GPRS+EGPRS multiplexing |
| 357 | |
| 358 | Both EGPRS and GPRS-only capable MS can be driven concurrently in the same PDCH |
| 359 | timeslot by the PCU, hence no special configuration is required per timeslot |
| 360 | regarding this topic; OsmoPCU scheduler takes care of the specific requirements |
| 361 | when driving MS with different capabilities. |
| 362 | |
| 363 | These specific requirements translate to some restrictions regarding which |
| 364 | Coding Schemes can be used at given frame numbers, and hence which kind of |
| 365 | RLCMAC blocks can be sent, which means serving a GPRS-only MS in a PDCH may end |
| 366 | up affecting slightly the downlink throughput of EGPRS capable MS. |
| 367 | |
| 368 | Throughput loss based on MS capabilities with TBF attached to a certain PDCH |
| 369 | timeslot: |
| 370 | |
| 371 | All UEs are EGPRS capable:: |
| 372 | No throughput loss, since all data is sent using EGPRS, and EGPRS control |
| 373 | messages are used when appropriate. |
| 374 | |
| 375 | All UEs are GPRS-only (doesn't support EGPRS):: |
| 376 | No throughput loss, since all data and control blocks use GPRS. |
| 377 | |
| 378 | Some UEs are GPRS-only, some EGPRS:: |
| 379 | In general EGPRS capable UEs will use EGPRS, and GPRS-only UEs will use GPRS, |
| 380 | with some restrictions affecting throughput of EGPRS capable UEs: |
| 381 | - Whenever a GPRS-only MS is to be polled to send uplink data to PCU, then a |
| 382 | downlink RLCMAC block modulated using GMSK must be sent, which means that if the |
| 383 | scheduler selects a EGPRS MS for downlink on that block it will force sending of |
| 384 | data with MCS1-4 (if it's new data, if it's a retransmission it cannot be |
| 385 | selected since MCS from original message cannot be changed). In the worst case |
| 386 | if no control block needs to be sent or no new data in MCS1-4 is available to |
| 387 | send, then an RLCMAC Dummy Block is sent. |
| 388 | - For synchronization purposes, each MS needs to receive an RLCMAC block which |
| 389 | it can fully decode at least every 360ms, which means the scheduler must enforce |
| 390 | a downlink block in CS1-4 every 360ms, that is, every 18th RLCMAC block. In |
| 391 | general this is not a big issue since anyway all control RLCMAC blocks are |
| 392 | encoded in CS1, so in case any control block is sent from time to time it's |
| 393 | accomplished and there's no penalty. However, if only EGPRS downlink data is sent |
| 394 | over that time frame, then the scheduler will force sending a RLCMAC Dummy |
| 395 | Block. |