Project

General

Profile

Actions

Feature #4544

closed

concurrent operation of GPRS and EGPRS mode

Added by laforge almost 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/12/2020
Due date:
% Done:

100%

Spec Reference:

Description

I'm trying to describe the problem domain here:

  • GPRS/EGPRS supports static and dynamic allocation of uplink resources
    • in static allocation, the UE gets told at which future frame numbers it is permitted to transmit in uplink
    • in dynamic allocation, every downlink block carries a "USF" value, and every TBF will get a grant to transmit in uplink if its USF value appears.
  • for real-world use cases, "dynamic" allocation is the only reasonable use case, unless you are exclusively dealing with streaming media where you you have a rather static bandwidth requirement. Also, some UE only support dynamic allocation to begin with
  • every UE must be able to decode every downlink block in order to know if its USF is transmitted or not
  • this works fine in GPRS as every UE can decode every block
  • once EGPRS is mixed with GPRS, you have some UE that can only decode GPRS/GMSK while others can decode EGRPS
  • as soon as you mix the two, and you have at least one GPRS-only uplink TBF, all downlink blocks must be GMSK and not 8PSK. This significantly degrades uplink pwerormance for all users

So in order to support both GPRS and EGPRS UE concurrently, we need to implement the above-mentioned logic, together with an extensive set of test cases.

There are some optimizations that can be done:
  • switch to a USF granularity of 4 blocks. at that point, only every 4th downlink block must be GMSK, while 3/4 of the blocks can remain 8PSK.
  • In the multi-TRX situations we are aiming for: Gather all GPRS-only UE one one (set of) TRX, while gathering EGPRS capable UE on other TRXs. This means that the EGPRS UEs can still use full 8PSK capbilities without any GPRS UE down-grading their performance.

By far the largest part will be writing test cases in a simulated environment (TTCN-3) as well as tests wih real UE. Once the tests exist, the related architectural changes to the PCU data model and the TBF scheduler/allocator can be implemented.

pespin will further investigate this.


Related issues

Related to OsmoPCU - Bug #4509: osmo-pcu rejects 8-bit RACH requests rejected on new MS when on "egprs only" modeClosedpespin04/22/2020

Actions
Related to OsmoPCU - Feature #1559: EGPRS/GPRS multiplexing on single PDCHClosed02/23/2016

Actions
Related to OsmoPCU - Feature #4286: Support configuration using 8PSK on dowlink while staying GMSK-only on uplinkResolvedlaforge11/28/2019

Actions
Related to OsmoPCU - Bug #4966: osmo-pcu: gprs+egprs multiplex: Allow selecting original 8-PSK dl block during retransmission for GMSK-required DL blockNew01/21/2021

Actions
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)