gprs_rlc_ul_window: Mark received BSNs falling out of the V(N)/RBB when V(R) is raised

This is a port of libosmo-gprs.git commit 49535bec37caddcea5718ed4e526c477c71f1b3a applied to osmo-pcu.

Problem this patch is fixing:
The current RLCMAC code is never invalidating the BSNs which have
been received after they are not needed.
This is somehow workaround by the following check when eg BSN wraps
around 127->0 and the BSN=0 is received:
""""
rcv_data_block_acknowledged()
	m_window.m_v_n.is_received(rdbi->bsn)
		/* Offset to the end of the received window */
		offset_v_r = (m_v_r - 1 - bsn) & mod_sns();
		return m_v_n.is_received(bsn) && offset_v_r < ws();
"""

The first m_v_n_is_received() would return true because the BSN has
never been invalidated, which is wrong, but fortunately the extra check
"offset_v_r < ws()" returns > ws() since:
v_r=0, bsn=0: "(0 - 1 - 0) & 127" ----> 0xffff & 0x007f ---> 0x007f > 64

So thanks to the above the BSN is considered not received, but looking
at the V(N) array would say the opposite. Hence, this commit aims at
fixing the V(N) array to contain proper values (marked "invalid") for
BSNs becoming out of the window when it rolls forward.

Explanation of the solution:
The V(N) array contains the status of the previous WS (64 in GPRS) data
blocks. This array is used to construct the RRB signaled to the peer
during PKT UL ACK/NACK messages together with the SSN (start sequence
number), which in our case is mainly V(R), aka one block higher than the
highest received block in the rx window.
Hence, whenever PKT UL ACK/NACK is transmitted, it contains an RRB
ranging [V(R)-1,...V(R)-WS)] mod SNS (SNS=128 in GPRS).

The receive window is basically [V(Q) <= BSN < V(R)] mod SNS, as is of
size 64.
The V(R) is increased whenever a highest new block arrives which is in the
receive window (guaranteeing it will be increased to at most V(Q)+64.

Since we are only announcing state of blocks from V(R)..V(R)-WS, and
blocks received which are before that BSN are dropped since don't fall
inside the rx window, we can securely mark as invalid those blocks
falling behind V(R)-WS whenever we increase V(R).

Related: OS#6102
Change-Id: I5ef4dcb0c5eac07a892114897f9e4f565b1dcc2c
3 files changed
tree: 789d9f9fd5d5960ea3eba48109920d1cbfee718e
  1. contrib/
  2. debian/
  3. doc/
  4. include/
  5. src/
  6. tests/
  7. .gitignore
  8. .gitreview
  9. configure.ac
  10. COPYING
  11. git-version-gen
  12. Makefile.am
  13. osmoappdesc.py
  14. README.md
  15. TODO
  16. TODO-RELEASE
README.md

osmo-pcu - Osmocom Packet Control Unit

This repository contains a C/C++-language implementation of a GPRS Packet Control Unit, as specified by ETSI/3GPP. It is part of the Osmocom Open Source Mobile Communications project.

The Packet Control Unit is terminating the Layer 2 (RLC/MAC) of the GPRS radio interface and adapting it to the Gb Interface (BSSGP+NS Protocol) towards the SGSN.

The PCU interfaces with the physical layer of the radio interface. OsmoPCU is typically used co-located with the BTS, specifically OsmoBTS. For legacy BTSs that run proprietary sotware without an interface to OsmoPCU, you may also co-locate it with the BSC, specifically OsmoBSC

Homepage

The official homepage of the project is https://osmocom.org/projects/osmopcu/wiki/OsmoPCU

GIT Repository

You can clone from the official osmo-pcu.git repository using

git clone https://gitea.osmocom.org/cellular-infrastructure/osmo-pcu

There is a web interface at https://gitea.osmocom.org/cellular-infrastructure/osmo-pcu

Documentation

We provide a user manual as well as a vty reference manual

Please note that a lot of the PCU configuration actually happens inside the BSC, which passes this configuration via A-bis OML to the BTS, which then in turn passes it via the PCU socket into OsmoPCU.

Mailing List

Discussions related to osmo-pcu are happening on the osmocom-net-gprs@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs for subscription options and the list archive.

Please observe the Osmocom Mailing List Rules when posting.

Contributing

Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards

We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details

The current patch queue for osmo-pcu can be seen at https://gerrit.osmocom.org/#/q/project:osmo-pcu+status:open

Current limitations

  • No PFC support
  • No fixed allocation support (was removed from 3GPP Rel >= 5 anyway)
  • No extended dynamic allocation support
  • No unacknowledged mode operation
  • Only single slot assignment on uplink direction
  • No half-duplex class support (only semi-duplex)
  • No TA loop
  • No power loop
  • Multi-BTS support not tested