401 lines
17 KiB
Plaintext
401 lines
17 KiB
Plaintext
== 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 CTRL interface (see OsmoBSC User Manual), since the
|
|
BSC is the node holding all the neighbor related information.
|
|
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.
|
|
|
|
These neighbor address resolutions (<ARFCN + BSIC> => <RAI + CI>) are by default
|
|
cached for a while in order to avoid querying the BSC frequently and, as a
|
|
result, optimizing the resolution time too.
|
|
|
|
.Example: Configure Neighbor Resolution CTRL interface against OsmoBSC
|
|
----
|
|
pcu
|
|
neighbor resolution 172.18.13.10 4248 <1>
|
|
timer X1 500 <2>
|
|
timer X0 60 <3>
|
|
----
|
|
<1> Port 4248 is the default and hence could be omitted in this case
|
|
<2> Time out if the BSC doesn't answer our CTRL resolution request after 500 ms
|
|
<3> Keep resolved neighbor addresses cached for 60 seconds
|
|
|
|
==== 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
|
|
|
|
|
|
=== 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.
|