Feature #1559
closed
EGPRS/GPRS multiplexing on single PDCH
Added by laforge about 8 years ago.
Updated over 3 years ago.
Description
is it worth doing? it slows down EGPRS once a single GPRS-only MS is around
- Related to Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAW added
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
- Related to Feature #4544: concurrent operation of GPRS and EGPRS mode added
- Status changed from New to Closed
Closing in favour of #4544
Also available in: Atom
PDF