| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If just a few bytes are left to send to the MS, it makes sense to
reduce the coding scheme level to increase the throughput. This
has been shown by Chen and Goodman in their paper "Theoretical
Analysis of GPRS Throughput and Delay". See their throughput over C/I
measurement graphs (figures 4 and 5 in the paper) for details.
This commit implements a simplified CS downgrade feature for the
downlink. The coding scheme will be downgraded if there are only a
few octets are left to be send over the TBF (see the
downgrade-threshold command below) and the NACK rate is not low (the
CS will not get degraded on a high quality RF link). As an exception,
CS-3 will be degraded to CS-1, since CS-2 does not improve the
throughput in general when a few small packets are sent and the
signal fades slowly (see Chen/Goodman).
The following VTY command is added to the config-pcu node:
- cs downgrade-threshold <1-10000>
- cs no downgrade-threshold
to set the threshold of the number of remaining bytes to be RLC/MAC
encoded. The CS will only be reduced, if the number is below the
threshold. The 'no' command disables this feature completely. The
default value is 200 octets.
Sponsored-by: On-Waves ehf
|
|
Currently the UL CS values are set to the corresponding DL CS value,
eventually limited by a maximum value. This approach does not reflect
the general situation of the RF link between ME and BTS, which is
rather asymmetric e.g. due to a lower degree of TX efficiency of the
built-in antenna. This means, that UL and DL CS control should be
decoupled for better results.
This commit adds automatic UL CS selection based on the link quality
measurement parameter. Each coding scheme is mapped to a link quality
range. If the link quality value leaves that range, the current UL CS
value is increased/decreased accordingly. This value will be copied
when the next PACKET_UPLINK_ACK_NACK or PACKET_UPLINK_ASSIGMENT is
sent to the MS.
The following VTY command will be added to the config-pcu node:
- cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35>
cs3 <0-35> <0-35> cs4 <0-35>
which sets the ranges for the four coding schemes. For instance the
example below reflects the current default values:
cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12
set the following ranges, where the overlapping is used to configure
a hysteresis:
CS1: -inf .. 6
CS2: 5 .. 8
CS3: 7 .. 13
CS4: 12 .. inf
Sponsored-by: On-Waves ehf
|
|
Currently only the RSSI value is passed to the upper layers. Other
values like TA and BER which are needed for TA update respectively CS
selection are not propagated.
This commit introduces and passes a struct that contains a set of
measurement values.
Sponsored-by: On-Waves ehf
|
|
Currently the CS values can be increased to CS4 even when the "cs"
configuration command has been used with a lower value. The "cs"
command just sets the initial coding scheme, so other means are
needed to limit the selection. One approach is to use the CS flags
passed in SI, but these are currently ignored.
To make it possible to limit the CS selection by configuring the PCU,
this commit adds the following VTY commands to config-pcu:
- cs max <1-4> Limit DL and UL CS to the given value
- cs max <1-4> <1-4> Limit DL and UL CS separately (DL first)
- no cs max Don't limit
Ticket: #1674
Sponsored-by: On-Waves ehf
|
|
To cope with transmission failures due to bad radio conditions, a
different coding scheme with more redundance can be used.
This commit adds an implemenation that is based on the Ack/Nack
ratio per PACKET DOWNLINK ACK/NACK message received from the MS.
Basically the CS level is decreased, if the block error rate goes
above cs_adj_upper_limit (default 33%), and it is increased, if the
rate drops below cs_adj_lower_limit (default 10%). Only blocks that
have been encoded with the current CS are taken into account.
Note that this approach doesn't measure the MS->BTS conditions and
that the measurement values reported by the MS are not taken into
account.
Ticket: #1739
Sponsored-by: On-Waves ehf
|
|
This commit sets the MS timeout when the MS object is created. The
value is taken from the ms_idle_sec field in gprs_rlcmac_bts which
can be changed by the VTY commands shown below.
The following VTY commands are added to the config-pcu node:
- ms-idle-time <1-7200> Set the timeout in seconds
- no ms-idle-time Disable the timeout
Another timer that is related is T3314 (Ready Timer, default 44s, GSM
24.008, 11.2.2) which requires the SGSN to use paging after its
expiry. Longer timeouts can help if adaptive coding scheme selection
is used (not yet implemented). On the other hand, measurement values
(TA, signal quality) can get invalid after some time, especially with
a moving MS. So a value slightly above T3314 is probably a good value
to start with.
Sponsored-by: On-Waves ehf
|
|
Currently the TA storage stores up to 30 TLLI->TA mappings, if more
entries are created the oldest one is dropped. In theory this can
lead to missing TA information if many MS are present.
This commit removes the TimingAdvance class completely, since the TA
value is now stored in the GprsMs objects.
Note that the GprsMs objects are currently not kept after the TBFs
have detached from them, so the TA values are now kept for a shorter
time than before.
Ticket: #1674
Sponsored-by: On-Waves ehf
|
|
Currently the BTS::trigger_dl_ass() method assigns the IMSI to the MS
object. This should be (and is already) done earlier where the MS
object is retrieved/created.
This commit removes the corresponding code along with the 'imsi'
parameter from trigger_dl_ass.
Sponsored-by: On-Waves ehf
|
|
Currently the TLLI is stored in each TBF. Since each MS is now
represented by a GprsMs object which takes care of TLLI updating,
and each TBF that has been associated with an TLLI also contains a
reference to a GprsMs object, per TBF TLLI handling is no longer
needed. Keeping all TBF m_tlli members up to date is complex and
doesn't currently work correctly in all circumstances.
This commit removes m_tlli and related members from the TBF class and
the tbf_by_tlli functions from the BTS class.
Ticket: #1674
Sponsored-by: On-Waves ehf
|
|
Use the MS storage to find a MS object for a given TLLI instead of
searching the TBF lists. The TBFs are then taken from the MS object,
if one has been found. If all TBF might be temporarily detached from
the MS object, a GprsMs::Guard is added to prevent the deletion of
the object, in case another TBF gets attached later on in the scope.
Ticket: #1674
Sponsored-by: On-Waves ehf
|
|
Currently the bucket size is by default being computed based on the
leak rate and the expected life time of LLC frames. The latter is
either taken from 'queue lifetime' (if given) or a fixed value is
used. Using 'queue lifetime' has the drawback that it sets a 'hard'
limit, since frames will be dropped if they stay in the queue
for a longer time.
This commit adds a VTY command to specifically set the time used for
the computation of the bucket size advertised to the SGSN. It does
not affect the PCUs queue handling in any way. If the bucket time is
not set (or if the 'no' command has been used), the old behaviour
(see above) is applied.
The following VTY commands are added (config-pcu node):
- flow-control bucket-time <1-65534> Sets the time in centisecs
- no flow-control bucket-time Don't use this time
Ticket: OW#1432
Sponsored-by: On-Waves ehf
|
|
Currently the FLOW-CONTROL_BVC message contains fixed values: The tag
is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is
820kbit/s, the MS bucket size is 50kB, and the MS leak rate is
50kbit/s.
This commit makes the BVC parameters configurable and adds the
following VTY commands:
- flow-control force-bvc-bucket-size <1-6553500>
- no flow-control force-bvc-bucket-size
- flow-control force-bvc-leak-rate <1-6553500>
- no flow-control force-bvc-leak-rate
- flow-control force-ms-bucket-size <1-6553500>
- no flow-control force-ms-bucket-size
- flow-control force-ms-leak-rate <1-6553500>
- no flow-control force-ms-leak-rate
The 'no' variants restore the default behaviour.
Sponsored-by: On-Waves ehf
|
|
If the protocol layers above LLC (e.g. TCP) need an acknowledgement
to continue, it can take up to 400ms (single TS) until the MS is
polled for Ack/Nack which it can use to request an uplink TBF
quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC
blocks until all pending LLC frames have been sent.
Especially TCP's slow start mechanism can lead to a high delay at the
start of the connection, since the sender will eventually stop after
having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)).
This commit modifies append_data() to (re-)start
a timer every time it handles an LLC packet and to request an
Ack/Nack every time it expires. So if the server ceases to send IP
packets, the MS is polled in the assumption, that the server is
waiting for an ACK.
The following VTY commands are added (pcu node):
- queue idle-ack-delay <1-65535> timeout in centiseconds
- no queue idle-ack-delay disable this feature (default)
A sensible value is 10 (100ms) that at gave promising results when
testing locally.
Sponsored-by: On-Waves ehf
|
|
Currently single LLC blocks are discarded when the PDU lifetime
expires. If an IP packet has been fragmented either on the IP or on
the LLC layer and is therefore distributed over several LLC frames,
the kept fragments are transmitted and then discarded by the MS
because of the missing PDU. This can cause massive IP packet loss
when there are many fragmented packets (e.g. when trying 'ping
-s1800' or if the GGSN chops downlink IP packets into several SNDCP
packets).
On the other hand, discarding too many packets might disturb the
congestion handling of TCP. Dropping plain TCP ACKs might also hinder
flow control and congestion avoidance.
This commit adds a hysteresis algorithm to the LLC discard loop. If
an LLC message's age reaches the high water mark, further message's
with an age above the low water mark are discarded, too. This is
aborted, if a GMM, a non-UI, or a small message is detected. In
these cases, that message is kept.
The following VTY commands are added (pcu config node):
- queue hysteresis <1-65535> set the difference between high
(lifetime) and low watermark in
centiseconds
- no queue hysteresis disable this feature (default)
Since the SGSN will most probably send all fragments of a single
N-PDU without much delay between them, a value slightly above the
average transmission delay jitter between SGSN and PCU is probably a
sensible value to discard all fragments of a single IP packet.
This is an experimental feature that might be replaced by more
advanced means of active queue management in the future.
Sponsored-by: On-Waves ehf
|
|
If an MS wants to open a new UL TBF, it can either use (P)RACH or
request one in a Ack/Nack message for a DL TBF (PACCH). When a TBF
becomes idle (LCC queue is empty but the TBF is kept open), there
aren't any Ack/Nack requests that can be used by the MS to ask for an
UL TBF, therefore it has to use the RACH. This leads to many RACH
requests even for a single HTTP transaction, so it takes some time to
retrieve even a simple web page.
This commit modifies the scheduler to regularly send Ack/Nack
requests on idle DL TBFs. It does so by extending the priority based
scheduling algorithm to have 5 priority levels (highest priority
first):
- Control block is pending
- High age (100%) threshold reached (-> request Ack/Nack)
- Data is waiting or there are pending Nacks
- Low age (200ms) threshold reached (-> request Ack/Nack)
- Pending Nacks that have been resent already
- None of the above (-> send DL dummy control block)
The 'age' refers to the time since since the last control block has
been sent on the TBF. This high age threshold is set to
dl-tbf-idle-time or to 50% of T3190 (whichever is smaller), aiming
for at least a poll (and TBF shutdown) after the TBF has expired and
to safely prevent expiry of T3190. So if dl-tbf-idle-time > 200ms,
there will be a poll every 200ms and a final poll after
dl-tbf-idle-time. On high load, the interval between polls can get
higher, but the 'high age' poll should be in place.
This commit implements the scheduling with respect to GSM 44.060,
9.3.1a ("Delayed release of downlink TBF").
Ticket: #556
Sponsored-by: On-Waves ehf
|
|
Currently a DL TBF is immediately closed, when the LLC queue is
drained. This will lead to a new DL assignment if data is received
afterwards. In addition, it is not possible to keep the PACCH open
to poll the MS for UL establishment requests there.
GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF
for some time (max 5s).
This commit mainly changes create_new_bsn() to send LLC dummy
commands as filler if no LLC data is available until keep_open()
returns false. The keep_open() functions returns true unless a
configurable time has passed after the LLC data store drained. By
default, that time is not set which causes keep_open() to always
return false, so that delayed release is effectively disabled.
The following VTY commands are added:
- dl-tbf-idle-time <1-5000> to set the delay in ms
- no dl-tbf-idle-time to disable delayed release
Ticket: #556
Sponsored-by: On-Waves ehf
|
|
This method is always called with a DL TBF as argument so make it clear.
Ticket: SYS#389
Sponsored by: On-Waves ehf
|
|
Start returning the special type instead of the base gprs_rlcmac_tbf
when retrieving a TBF.
Ticket: SYS#389
Sponsored-by: On-Waves ehf
|
|
In the lookup functions make sure that we are actually returning tbfs
with the expected direction.
Ticket: SYS#389
Sponsored-by: On-Waves ehf
|
|
rcv_control_dl_ack_nack is only meaningful for dl tbf while
rcv_control_ack can be sent in response to a dl or ul tbf. So
rcv_control_ack still needs to check for ul and dl tbfs.
Ticket: SYS#389
Sponsored-by: On-Waves ehf
|
|
Ticket: SYS#389
Sponsored-by: On-Waves ehf
|
|
In the future we want to separate ul and dl tbf into different
classes that inherit from a common base.
Ticket: SYS#389
Sponsored-by: On-Waves ehf
|
|
The current code keeps a reference to all tbfs in the bts and another
reference in the pdch. This allows for the possibility of both lists to
go out of sync.
This patch removes the pdch-specific list of ul and dl tbfs and uses the
lists in the bts to lookup tbfs everywhere.
Performance for going through the global list is not an issue yet. We
can optimize this later and in a better way.
Sponsored-by: On-Waves ehf
|
|
This patch introduces methods to get ul and dl tbf by tfi and uses them
in gprs_rlcmac_sched.
Sponsored by: On-Waves ehf
|
|
It is possible that certain UL ACK messages are not sent when there
are many many uplink and downlink assignments. Try to be more fair
and schedule them round-robin. This way no starvation should occur.
|
|
There appears to be a scheduling issue. Even without any NACKs
we are re-transmitting a lot of frames. It might be because of
this.
|
|
|
|
|
|
|
|
This does not mean that they have been successfully transferred
to the SGSN/MS but at least that they have reached a certain point
in the message flow.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Move the code to a new method
|
|
Kill the tlli assignment as it is never used.
|
|
Kill the unused tfi parameter
|
|
|
|
A DL tbf can be discarded and then the already queued LLCs will
be silently dropped. Count this event.
|
|
Add a warning about the receive message poking in the internal
of the sba. This will be cleaned up in a follow up commit
|
|
|
|
|
|
|
|
|
|
Move the gprs_rlcmac_poll_timeout method into the tbf class and
gprs_rlcmac_downlink_assignment into the BTS.
|
|
|
|
|
|
|
