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

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

As a reminder:

- GPRS supports Coding Schemes 1-4 (CS1-4), all of them use GMSK modulation
  (same as GSM).
- EGPRS supports MCS1-9, where MCS1-4 is GMSK, and MCS5-9 use 8-PSK modulation.

The range of Coding Schemes above only apply to RLCMAC data blocks; RLCMAC
control blocks are always transmitted with CS1 (GMSK). Hence, CS1 is always
supported and must be always permitted.

The BSC includes a bit-mask of permitted [E]GPRS coding schemes as part of the
A-bis OML configuration, controlled by VTY `gprs mode (none|gprs|egprs)`.  This
is passed from the BTS via the PCU socket into OsmoPCU, and the resulting set
can be further constrained by OsmoPCU VTY configuration.

Some additional OsmoPCU 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.

Similarly, `mcs <1-9> [<1-9>]` can be used to set up the initial EGPRS coding
scheme.

[[max_cs_mcs]]
==== Maximum Coding Scheme

You can use the `cs max <1-4> [<1-4>]` command at the `pcu` VTY config
node to set the maximum GPRS coding scheme that should be used as part of the
rate adaption.  The optional second value allows to specify a different maximum
coding scheme for uplink.

Similarly, `mcs max <1-9> [<1-9>]` can be used to set up the maximum EGPRS
coding scheme.

The actual Maximum Coding Scheme for each direction used at runtime is actually
the result of taking the maximum value from the permitted GPRS coding schemes
received by the BSC (or BTS) over PCUIF which is equal or lower tho the
configured value.

Example: PCUIF announces permitted MCS bit-mask (`MCS1 MCS2 MCS3 MCS4`) and
OsmoPCU is configured `mcs max 6`, then the actual maximum MCS used at runtime
will be `MCS4`.

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

`gamma <0-62>`::
	Set the gamma parameter for MS power control in units of dB.

Parameter `ALPHA` is set on the BSC VTY configuration file on a per-BTS basis,
and forwarded by OsmoPCU to the MS through the SI13 received from the former
over PCUIF. OsmoPCU VTY command `alpha <0-10>` overrides the value received over
PCUIF to keep backward compatibility with existing config files, but it is
currently deprecated and its use is discouraged; one should configure it per-BTS
in OsmoBSC VTY instead.

=== Configuring Network Assisted Cell Change (NACC)

Network Assisted Cell Change, defined in 3GPP TS 44.060 sub-clause 8.8, is a
feature providing the MS aid when changing to a new cell due to autonomous
reselection. In summary, the MS informs the current cell its intention to change
to a new target cell, and the network decides whether to grant the intended cell
change or order a change to another neighbor cell. It also provides several
System Informations of the target cell to the MS to allow for quicker
reselection towards it.

OsmoPCU will automatically provide the required neighbor System Information when
the MS requests NACC towards a target cell also under the management of the same
OsmoPCU instance, since it already has the System Information of all BTS under
their control, obtained through PCUIF when the BTS registers against OsmoPCU, so
no specific user configuration is required here.

In general, OsmoPCU requires to gather the information from somewhere else
before being able to provide it to the MS requesting the NACC.

If OsmoPCU fails to gather the System Information, it will simply answer the MS
allowing the proposed changed but without previously providing the System
Information of the target cell.

==== Neighbor Address Resolution

First of all, it needs to translate the <ARFCN + BSIC> identity of the target
cell to change to, provided by the MS, into an identity that the Core Network
can use and understand to identify the target cell, which happens to be a key
composed of <RAI + Cell Identity>. This key is also named conveniently as
CGI-PS, since it actually equals to the Circuit Switch CGI + RAC.

In order to apply this target cell identity translation, OsmoPCU uses the
OsmoBSC Neighbor Resolution Service. This service is nowadays provided by means
of PCUIF container messages, which are transparently forwarded in both directions
by the BTS using the IPA multiplex of the OML connection against the BSC. No
specific configuration is required in any of the involved nodes, they should
behave properly out of the box.

These neighbor address resolutions (<ARFCN + BSIC> => <RAI + CI>) are by default
cached for a while, in order to avoid querying the BSC frequently. As a result,
the resolution time is also optimized.

.Example: Configure Neighbor Resolution cache and timeouts
----
pcu
 timer X1 500 <1>
 timer X0 60 <2>
----
<1> Time out if the BSC doesn't answer our resolution request after 500 ms
<2> Keep resolved neighbor addresses cached for 60 seconds

===== OsmoBSC CTRL interface (deprecated)

CAUTION: This interface is nowadays considered deprecated and should not be used
anymore. Any related VTY options should be dropped from configuration files, to
let OsmoPCU use the new interface instead. This section is kept here for a while
as a reference for old deployments using old versions of the programs.

This Neighbor Address Resolution Service was initially implemented by means of a
separate CTRL interface (see OsmoBSC User Manual), where OsmoPCU would create a
CTRL connection to the BSC each time an address resolution was required.

Older versions of OsmoBSC may not support the current Neighbor Address
Resolution Service over the IPA multiplex (see above). For those cases, OsmoPCU
can be configured to use the old deprecated CTRL interface.

By default, the use of this interface is not configured and hence disabled in
OsmoPCU. As a result, until configured, the network won't be able to provide the
System Information to the MS prior to allowing the change during NACC against
remote cells, which means the cell change will take longer to complete. In order
to configure the interface, the OsmoBSC IP address and port to connect to must
be configured in OsmoPCU VTY.

.Example: Configure Neighbor Resolution CTRL interface against OsmoBSC
----
pcu
 neighbor resolution 172.18.13.10 4248 <1>
----
<1> Port 4248 is the default and hence could be omitted in this case

==== System Information Resolution

Once OsmoPCU gains knowledge of the target cell's address in the Core Network,
it can query its System Information.

OsmoPCU will gather the requested System Information of target cells under its
control without need for any external query, since the System Information of all
BTSs it manages are received over PCUIF and stored internally in OsmoPCU.

For those targets cells not managed by the OsmoPCU instance, the query is
accomplished by using RIM procedures (NACC RAN-INFO application) over the Gb
interface against the SGSN that OsmoPCU is connected to. In its turn, the SGSN
will potentially forward this query to the PCU serving the target cell, which
will provide back the System Information of that cell.

The System Information received from external PCUs over RIM are by default
cached for a while in order to avoid querying the SGSN frequently and, as a
result, optimizing the resolution time too.

.Example: Configure System Information resolution
----
pcu
 timer X2 500 <1>
 timer X11 60 <2>
----
<1> Time out if the SGSN doesn't answer our RIM RAN-INFO request request after 500 ms
<2> Keep resolved remote neighbor System Information cached for 60 seconds

[[cfg_e1_line]]
=== Configuring E1 line for CCU access

Depending on the configuration the PCU may require direct access to a BTS CCU
(channel coding unit) via an E1 line. This is in particular the case when
OsmoPCU runs in co-location with OsmoBSC.

The exact timeslot configuration is passed to the PCU via the pcu_sock
interface. Only basic E1 line settings are required. However, it is important
that the E1 line number is the same as the E1 line number that is used in the
timeslot configuration of OsmoBSC.

.Example: Configure an E1 line
----
e1_input
 e1_line 0 driver dahdi
 e1_line 0 port 2
 no e1_line 0 keepalive
----

=== GPRS vs EGPRS considerations

==== Configuration

OsmoPCU can be configured to either:

- Allocate only GPRS TBFs to all MS (no EGPRS)
- Allocate EGPRS TBFs to EGPRS capable phones while still falling back to
  allocating GPRS TBFs on GPRS-only capable MS.

These two different modes of operation are selected by properly configuring the
Coding Schemes (see <<max_cs_mcs>>).

The first mode of operation (GPRS-only for all MS) can be accomplished
configuring OsmoPCU so that the resulting MCS set is empty. This can be done in
two ways:

- Announcing an empty MCS bit-mask over PCUIF to OsmoPCU:
  That's actually done automatically by OsmoBSC on BTS with VTY config set to
  `gprs mode gprs`.
- Configuring OsmoPCU to force an empty set by using VTY command `mcs max 0`.

Hence, if the resulting MCS bit-mask is not empty, (BSC configuring the BTS with
`gprs mode egprs` and OsmoPCU VTY containing something other than 'mcs max 0'),
EGPRS TBFs will be allocated for all MS announcing EGPRS capabilities.

It is important to remark that in order to use MCS5-9, the BTS must support
8-PSK modulation. Nevertheless, in case 8-PSK is not supported by the BTS, one
can still enable EGPRS and simply make sure 8-PSK MCS are never used by
configuring OsmoPCU with `mcs max 4 4`.

Similarly, a BTS may support 8-PSK modulation only on downlink, since it is
easier to implement than the uplink, together with the fact that higher downlink
throughput is usually more interesting from user point of view. In this
scenario, OsmoPCU can be configured to allow for full MCS range in downlink
while still preventing use of 8-PSK on the uplink: `mcs max 9 4`.

Some other interesting configurations to control use of EGPRS in the network
which lay outside OsmoPCU include:

- If `osmo-bts-trx` together with `osmo-trx` is used, remember to enable EGPRS
  support (OsmoTRX VTY `egprs enable`).

- It is possible to improve EGPRS performance (in particular, the TBF
  establishment timing) a bit by enabling 11-bit Access Burst support. This
  allows EGPRS capable phones to indicate their EGPRS capability, establishment
  cause, and multi-slot class directly in the Access Burst (OsmoTRX VTY
  `ext-rach enable`, OsmoBSC VTY `gprs egprs-packet-channel-request`).

NOTE: If you enable MCS5-9 you will also need an 8-PSK capable OsmoBTS+PHY,
which means `osmo-bts-sysmo` or `osmo-bts-litecell15` with their associated PHY,
or `osmo-bts-trx` with `osmo-trx` properly configured.

==== GPRS+EGPRS multiplexing

Both EGPRS and GPRS-only capable MS can be driven concurrently in the same PDCH
timeslot by the PCU, hence no special configuration is required per timeslot
regarding this topic; OsmoPCU scheduler takes care of the specific requirements
when driving MS with different capabilities.

These specific requirements translate to some restrictions regarding which
Coding Schemes can be used at given frame numbers, and hence which kind of
RLCMAC blocks can be sent, which means serving a GPRS-only MS in a PDCH may end
up affecting slightly the downlink throughput of EGPRS capable MS.

Throughput loss based on MS capabilities with TBF attached to a certain PDCH
timeslot:

All UEs are EGPRS capable::
 No throughput loss, since all data is sent using EGPRS, and EGPRS control
 messages are used when appropriate.

All UEs are GPRS-only (doesn't support EGPRS)::
 No throughput loss, since all data and control blocks use GPRS.

Some UEs are GPRS-only, some EGPRS::
In general EGPRS capable UEs will use EGPRS, and GPRS-only UEs will use GPRS,
with some restrictions affecting throughput of EGPRS capable UEs:
- Whenever a GPRS-only MS is to be polled to send uplink data to PCU, then a
downlink RLCMAC block modulated using GMSK must be sent, which means that if the
scheduler selects a EGPRS MS for downlink on that block it will force sending of
data with MCS1-4 (if it's new data, if it's a retransmission it cannot be
selected since MCS from original message cannot be changed). In the worst case
if no control block needs to be sent or no new data in MCS1-4 is available to
send, then an RLCMAC Dummy Block is sent.
- For synchronization purposes, each MS needs to receive an RLCMAC block which
it can fully decode at least every 360ms, which means the scheduler must enforce
a downlink block in CS1-4 every 360ms, that is, every 18th RLCMAC block. In
general this is not a big issue since anyway all control RLCMAC blocks are
encoded in CS1, so in case any control block is sent from time to time it's
accomplished and there's no penalty. However, if only EGPRS downlink data is sent
over that time frame, then the scheduler will force sending a RLCMAC Dummy
Block.

[[gsmtap]]
=== Configuring GSMTAP tracing

In addition to being able to obtain pcap protocol traces of the NS/BSSGP
communication and the text-based logging from the OsmoPCU software, there is
also the capability of tracing all communication on the radio interface related
to PS. To do so, OsmoPCU can encapsulate MAC blocks (23-155 byte messages at the
L2-L1 interface depending on coding scheme) into _GSMTAP_ and send them via
UDP/IP. At that point, they can be captured with utilities like *tcpdump* or
*tshark* for further analysis by the *wireshark* protocol analyzer.

In order to activate this feature, you first need to make sure to specify
the remote address of _GSMTAP_ host in the configuration file.  In most
cases, using 127.0.0.1 for passing the messages over the loopback (`lo`)
device will be sufficient:

.Example: Enabling GSMTAP Um-frame logging to localhost
----
pcu
 gsmtap-remote-host 127.0.0.1 <1>
----
<1> Destination address for _GSMTAP_ Um-frames

NOTE: Changing this parameter at run-time will not affect the existing
_GSMTAP_ connection, full program restart is required.

NOTE: Command line parameters `-i` and `--gsmtap-ip` have been deprecated.

OsmoPCU can selectively trace such messages based on different categories, for
both Ul and Dl. For a complete list of cateogry values, please refer to the
_OsmoPCU VTY reference manual_ <<vty-ref-osmopcu>>.

For example, to enable GSMTAP tracing for all DL EGPRS rlcmac data blocks, you
can use the `gsmtap-category dl-data-egprs` command at the `pcu` node of the
OsmoPCU VTY.

.Example: Enabling  GSMTAP for for all DL EGPRS rlcmac data blocks
----
OsmoPCU> enable
OsmoPCU# configure terminal
OsmoPCU(config)# pcu
OsmoPCU(pcu)# gsmtap-category dl-data-egprs
OsmoPCU(trx)# write <1>
----
<1> the `write` command will make the configuration persistent in the
configuration file.  This is not required if you wish to enable GSMTAP
only in the current session of OsmoPCU.

De-activation can be performed similarly by using the `no gsmtap-category
dl-data-egprs` command at the `pcu` node of the OsmoPCU VTY.

It may be useful to enable all categories with a few exceptions, or vice versa
disable everything using one command.  For this purpose, the VTY provides
`gsmtap-category enable-all` and `gsmtap-category disable-all` commands.

.Example: Enabling all categoriess except _dl-dummy_
----
pcu
 gsmtap-category enable-all <1>
 no gsmtap-category dl-dummy <2>
----
<1> Enable all available SAPIs
<2> Exclude DL RLCMAC blocks

From the moment they are enabled via VTY, GSMTAP messages will be
generated and sent in UDP encapsulation to the IANA-registered UDP port
for GSMTAP (4729) of the specified remote address.