| == Configuring OsmoPCU |
| |
| Contrary to other network elements (like OsmoBSC, OsmoNITB), the |
| OsmoPCU has a relatively simple minimum configuration. |
| |
| This is primarily because most of the PCU configuration happens |
| indirectly from the BSC, who passes the configuation over A-bis OML via |
| OsmoBTS and its PCU socket into OsmoPCU. |
| |
| A minimal OsmoPCU configuration file is provided below for your reference: |
| |
| .Example: Minimal OsmoPCU configuration file (`osmo-pcu.cfg`) |
| ---- |
| pcu |
| flow-control-interval 10 <1> |
| cs 2 <2> |
| alloc-algorithm dynamic <3> |
| alpha 0 <4> |
| gamma 0 |
| ---- |
| <1> send a BSSGP flow-control PDU every 10 seconds |
| <2> start a TBF with the initial coding scheme 2 |
| <3> dynamically chose between single-slot or multi-slot TBF allocations |
| depending on system load |
| <4> disable MS power control loop |
| |
| However, there are plenty of tuning parameters for people interested to |
| optimize PCU throughput or latency according to their requirements. |
| |
| === Configuring the Coding Schemes and Rate Adaption |
| |
| The BSC includes a bit-mask of permitted [E]GPRS coding schemes as part |
| of the A-bis OML configuration. This is passed from the BTS via the PCU |
| socket into OsmoPCU. |
| |
| Some additional parameters can be set as described below. |
| |
| ==== Initial Coding Scheme |
| |
| You can use the `cs <1-4> [<1-4>]` command at the `pcu` VTY config node |
| to set the initial GPRS coding scheme to be used. The optional second |
| value allows to specify a different initial coding scheme for uplink. |
| |
| ==== Maximum Coding Scheme |
| |
| You can use the `cs max <1-4> [<1-4>]` command at the `pcu` VTY config |
| node to set the maximum coding scheme that should be used as part of the |
| rate adaption. |
| |
| ==== Rate Adaption Error Thresholds |
| |
| You can use the `cs threshold <0-100> <0-100>` command at the `pcu` VTY |
| config node to determine the upper and lower limit for the error rate |
| percentage to use in the rate adaption. If the upper threshold is |
| reached, a lower coding sheme is chosen, and if the lower threshold is |
| reached, a higher coding scheme is chosen. |
| |
| ==== Rate Adation Link Quality Thresholds |
| |
| You can use the `cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 |
| <0-35> <0-35> cs4 <0-35>` command at the `pcu` VTY config node to tune |
| the link quality ranges for the respective coding schemes. |
| |
| ==== Data Size based CS downgrade Threshold |
| |
| You can use the `cs downgrade-threshold <1-10000>` command at the `pcu` |
| VTY config node to ask the PCU to down-grade the coding scheme if less |
| than the specified number of octets are left to be transmitted. |
| |
| === Miscellaneous Configuration / Tuning Parameters |
| |
| ==== Downlink TBF idle time |
| |
| After a down-link TBF is idle (all data in the current LLC downlink |
| queue for the MS has been transmitted), we can keep the TBF established |
| for a configurable time. This avoids having to go through a new one or |
| two phase TBF establishment once the next data for downlink arrives. |
| |
| You can use the `dl-tbf-idle-time <1-5000>` to specify that time in |
| units of milli-seconds. The default is 2 seconds. |
| |
| ==== MS idle time |
| |
| Using the `ms-idle-time <1-7200>` command at the `pcu` VTY config node |
| you can configure the number of seconds for which the PCU should keep |
| the MS data structure alive before releasing it if there are no active |
| TBF for this MS. |
| |
| The OsmoPCU default value is 60 seconds, which is slightly more than |
| what 3GPP TS 24.008 recommends for T3314 (44s). |
| |
| The MS data structure only consumes memory in the PCU and does not |
| require any resources of the air interface. |
| |
| ==== Forcing two-phase access |
| |
| If the MS is using a single-phase access, you can still force it to |
| use a two-phase access using the `two-phase-access` VTY configuration |
| command at the `pcu` VTY config node. |
| |
| === Configuring BSSGP flow control |
| |
| BSSGP between SGSN and PCU contains a two-level nested flow control |
| mechanism: |
| |
| . one global flow control instance for the overall (downlink) traffic |
| from the SGSN to this PCU |
| . a per-MS flow control instance for each individual MS served by this |
| PCU |
| |
| Each of the flow control instance is implemented as a TBF (token bucket |
| filter). |
| |
| ==== Normal BSSGP Flow Control Tuning parameters |
| |
| You can use the following commands at the `pcu` VTY config node to tune |
| the BSSGP flow control parameters: |
| |
| `flow-control-interval <1-10>`:: |
| configure the interval (in seconds) between subsequent flow |
| control PDUs from PCU to SGSN |
| `flow-control bucket-time <1-65534>`:: |
| set the target downlink maximum queueing time in centi-seconds. |
| The PCU will attempt to adjust the advertised bucket size to match this |
| target. |
| |
| ==== Extended BSSGP Flow Control Tuning parameters |
| |
| There are some extended flow control related parameters at the `pcu` VTY |
| config node that override the automatic flow control as specified in the |
| BSSGP specification. Use them with care! |
| |
| `flow-control force-bvc-bucket-size <1-6553500>`:: |
| force the BVC (global) bucket size to the given number of octets |
| `flow-control force-bvc-leak-rate <1-6553500>`:: |
| force the BVC (global) bucket leak rate to the given number of bits/s |
| `flow-control force-ms-bucket-size <1-6553500>`:: |
| force the per-MS bucket size to the given number of octets |
| `flow-control force-ms-leak-rate <1-6553500>`:: |
| force the per-MS bucket leak rate to the given number of bits/s |
| |
| |
| === Configuring LLC queue |
| |
| The downlink LLC queue in the PCU towards the MS can be tuned with a |
| variety of parameters at the `pcu` VTY config node, depending on your |
| needs. |
| |
| `queue lifetime <1-65534>`:: |
| Each downlink LLC PDU is assigned a lifetime by the SGSN, which |
| is respected by the PDU *unless* you use this command to |
| override the PDU lifetime with a larger value (in centi-seconds) |
| `queue lifetime infinite`:: |
| Never drop LLC PDUs, i.e. give them an unlimited lifetime. |
| `queue hysteresis <1-65535>`:: |
| When the downlink LLC queue is full, the PCU starts dropping |
| packets. Using this parameter, we can set the lifetime |
| hysteresis in centi-seconds, i.e. it will continue discarding |
| until "lifetime - hysteresis" is reached. |
| `queue codel`:: |
| Use the 'CoDel' (Controlled Delay) scheduling algorithm, which |
| is designed to overcome buffer bloat. It will use a default |
| interval of 4 seconds. |
| `queue codel interval <1-1000>`:: |
| Use the 'CoDel' (Controlled Delay) scheduling algorithm, which |
| is designed to overcome buffer bloat. Use the specified |
| interval in centi-seconds. |
| `queue idle-ack-delay <1-65535>`:: |
| Delay the request for an ACK after the last downlink LLC frame |
| by the specified amount of centi-seconds. |
| |
| |
| === Configuring MS power control |
| |
| GPRS MS power control works completely different than the close MS power |
| control loop in circuit-switched GSM. |
| |
| Rather than instructing the MS constantly about which transmit power to |
| use, some parameters are provided to the MS by which the MS-based power |
| control algorithm is tuned. |
| |
| See 3GPP TS 05.08 for further information on the algorithm and the |
| parameters. |
| |
| You can set those parameters at the `pcu` VTY config node as follows: |
| |
| `alpha <0-10>`:: |
| Alpha parameter for MS power control in units of 0.1. |
| Make sure to set the alpha value at System Information 13 (in |
| the BSC), too! |
| `gamma <0-62>`:: |
| Set the gamma parameter for MS power control in units of dB. |
| |
| |
| === Enabling EGPRS |
| |
| If you would like to test the currently (experimental) EGPRS support of |
| OsmoPCU, you can enable it using the `egprs` command at the `pcu` VTY |
| config node. |
| |
| WARNING: EPGRS functionality is highly experimental at the time of this |
| writing. Please only use if you actively would like to participate in |
| the OsmoPCU EGPRS development and/or testing. You will also need an |
| EGPRS capable OsmoBTS+PHY, which means `osmo-bts-sysmo` or |
| `osmo-bts-litecell15` with their associated PHY. |