Project

General

Profile

Feature #1559

EGPRS/GPRS multiplexing on single PDCH

Added by laforge over 4 years ago. Updated 8 months ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

0%

Spec Reference:

Description

is it worth doing? it slows down EGPRS once a single GPRS-only MS is around


Related issues

Related to OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWIn Progress12/23/2019

History

#1 Updated by pespin 8 months ago

  • Related to Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAW added

#2 Updated by pespin 8 months ago

From laforge in #4338:

[Currently] osmo-pcu supports either GPRS or EGPRS. That means, as soon as you turn on EGPRS,
you loose backwards compatibility to non-EGPRS phones. Due to that somewhat strange and unusual
(in terms of other implementations) behavior, it shouldn't happen dynamically/automatically,
but should be very explicit choice by the user. the "only" ("egprs only") in the vty command also expresses
that.

I believe there are some ancient tickets about this. The reason for
lack of GPRS backwards compatibility was to first get GPRS and EGPRS by
themselves working reliably and tested, and then (if ever) implement the
backwards compatibility. I think the main problem is that there are
some parts of downlink PDCH which all (or at least all MS with active
TBF) need to be able to parse, and in a mixed GPRS + EGPRS cell you then
need to not only look at your own TBF/MS capabilities, but also at those
of all the other MS to determine if you can send such information in MCS
or if you must send it in CS. I think it already starts with things
like TFI and USF, which must be decoded by all MS with active TBF.

Related information can be found here, page 83:
https://issuu.com/leliwa/docs/signalling_in_gprs_egprs_chapter_03

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)