Actions
Feature #1559
closedEGPRS/GPRS multiplexing on single PDCH
Status:
Closed
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
Updated by pespin over 4 years ago
- Related to Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAW added
Updated by pespin over 4 years ago
[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
Updated by pespin over 3 years ago
- Related to Feature #4544: concurrent operation of GPRS and EGPRS mode added
Actions