1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
== 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.
|
