Change in osmo-pcu[master]: doc: Improve CS/MCS GPRS/EGPRS considerations in User Manual

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Tue Jan 5 12:27:33 UTC 2021


pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-pcu/+/21943 )


Change subject: doc: Improve CS/MCS GPRS/EGPRS considerations in User Manual
......................................................................

doc: Improve CS/MCS GPRS/EGPRS considerations in User Manual

Related: OS#4544
Related: SYS#4869
Change-Id: I7b205f5cab5862058a408f628925beb9f0f60a92
---
M doc/manuals/chapters/configuration.adoc
1 file changed, 128 insertions(+), 10 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-pcu refs/changes/43/21943/1

diff --git a/doc/manuals/chapters/configuration.adoc b/doc/manuals/chapters/configuration.adoc
index 6fc61c7..3e76879 100644
--- a/doc/manuals/chapters/configuration.adoc
+++ b/doc/manuals/chapters/configuration.adoc
@@ -29,11 +29,22 @@
 
 === Configuring the Coding Schemes and Rate Adaption
 
-The BSC includes a bit-mask of permitted [E]GPRS coding schemes as part
-of the A-bis OML configuration.  This is passed from the BTS via the PCU
-socket into OsmoPCU.
+As a reminder:
 
-Some additional parameters can be set as described below.
+- GPRS supports Coding Schemes 1-4 (CS1-4), all of them use GMSK modulation
+  (same as GSM).
+- EGPRS supports MCS1-9, where MCS1-4 is GMSK, and MCS5-9 use 8-PSK modulation.
+
+The range of Coding Schemes above only apply to RLCMAC data blocks; RLCMAC
+control blocks are always transmitted with CS1 (GMSK). Hence, CS1 is always
+supported and must be always permitted.
+
+The BSC includes a bit-mask of permitted [E]GPRS coding schemes as part of the
+A-bis OML configuration, controlled by VTY `gprs mode (none|gprs|egprs)`.  This
+is passed from the BTS via the PCU socket into OsmoPCU, and the resulting set
+can be further constrained by OsmoPCU VTY configuration.
+
+Some additional OsmoPCU parameters can be set as described below.
 
 ==== Initial Coding Scheme
 
@@ -41,11 +52,28 @@
 to set the initial GPRS coding scheme to be used.  The optional second
 value allows to specify a different initial coding scheme for uplink.
 
+Similarly, `mcs <1-9> [<1-9>]` can be used to set up the initial EGPRS coding
+scheme.
+
+[[max_cs_mcs]]
 ==== Maximum Coding Scheme
 
 You can use the `cs max <1-4> [<1-4>]` command at the `pcu` VTY config
-node to set the maximum coding scheme that should be used as part of the
-rate adaption.
+node to set the maximum GPRS coding scheme that should be used as part of the
+rate adaption.  The optional second value allows to specify a different maximum
+coding scheme for uplink.
+
+Similarly, `mcs max <1-9> [<1-9>]` can be used to set up the maximum EGPRS
+coding scheme.
+
+The actual Maximum Coding Scheme for each direction used at runtime is actually
+the result of taking the maximum value from the permitted GPRS coding schemes
+received by the BSC (or BTS) over PCUIF which is equal or lower tho the
+configured value.
+
+Example: PCUIF announces permitted MCS bit-mask (`MCS1 MCS2 MCS3 MCS4`) and
+OsmoPCU is configured `mcs max 6`, then the actual maximum MCS used at runtime
+will be `MCS4`.
 
 ==== Rate Adaption Error Thresholds
 
@@ -192,11 +220,101 @@
 	Set the gamma parameter for MS power control in units of dB.
 
 
-=== Enabling EGPRS
+=== GPRS vs EGPRS considerations
 
-If you would like to test the currently (experimental) EGPRS support of
-OsmoPCU, you can enable it using the `egprs` command at the `pcu` VTY
-config  node.
+==== Configuration
+
+OsmoPCU can be configured to either:
+
+- Allocate only GPRS TBFs to all MS (no EGPRS)
+- Allocate EGPRS TBFs to EGPRS capable phones while still falling back to
+  allocating GPRS TBFs on GPRS-only capable MS.
+
+These two different modes of operation are selected by properly configuring the
+Coding Schemes (see <<max_cs_mcs>>).
+
+The first mode of operation (GPRS-only for all MS) can be accomplished
+configuring OsmoPCU so that the resulting MCS set is empty. This can be done in
+two ways:
+
+- Announcing an empty MCS bit-mask over PCUIF to OsmoPCU:
+  That's actually done automatically by OsmoBSC on BTS with VTY config set to
+  `gprs mode gprs`.
+- Configuring OsmoPCU to force an empty set by using VTY command `mcs max 0`.
+
+Hence, if the resulting MCS bit-mask is not empty, (BSC configuring the BTS with
+`gprs mode egprs` and OsmoPCU VTY conftaining something other than 'mcs max 0'),
+EGPRS TBFs will be allocated for all MS announcing EGPRS capabilities.
+
+It is important to remark that in order to use MCS5-9, the BTS must support
+encoding and decoding of 8-PSK modulation. Nevertheless, in the event 8-PSK is not
+supported on the BTS, one can still enable EGPRS and simply make sure 8-PSK MCS
+are never used by configuring OsmoPCU with `mcs max 4 4`.
+
+Similarly, a BTS may support 8-PSK modulation only on downlink, since it is
+easier to implement than the uplink, together with the fact that higher downlink
+throughput is usually more interesting from user point of view. In this
+scenario, OsmoPCU can be configured to allow for full MCS range in downlink
+while still preventing use of 8-PSK on the uplink: `mcs max 9 4`.
+
+Some other interesting configurations to control use of EGPRS in the network
+which lay outside OsmoPCU include:
+
+- If `osmo-bts-trx` together with `osmo-trx` is used, remember to enable EGPRS
+  support (OsmoTRX VTY `egprs enable`).
+
+- It is possible to improve EGPRS performance (in particular, the TBF
+  establishment timing) a bit by enabling 11-bit Access Burst support. This
+  allows EGPRS capable phones to indicate their EGPRS capability, establishment
+  cause, and multi-slot class directly in the Access Burst (OsmoTRX VTY
+  `ext-rach enable`, OsmoBSC VTY `gprs egprs-packet-channel-request`).
+
+NOTE: If you enable MCS5-9 you will also need an 8-PSK capable OsmoBTS+PHY,
+which means `osmo-bts-sysmo` or `osmo-bts-litecell15` with their associated PHY,
+or `osmo-bts-trx` with `osmo-trx` properly configured.
+
+==== GPRS+EGPRS multiplexing
+
+Both EGPRS and GPRS-only capable MS can be driven concurrently in the same PDCH
+timeslot by the PCU, hence no special configuration is required per timeslot
+regarding this topic; OsmoPCU scheduler takes care of the specific requirements
+when driving MS with different capabilities.
+
+These specific requirements translate to some restrictions regarding which
+Coding Schemes can be used at given frame numbers, and hence which kind of
+RLCMAC blocks can be sent, which means serving a GPRS-only MS in a PDCH may end
+up affecting slightly the downlink throughput of EGPRS capable MS.
+
+Throughput loss based on MS capabilities with TBF attached to a certain PDCH
+timeslot:
+
+All UEs are EGPRS capable::
+ No throughput loss, since all data is sent using EGPRS, and EGPRS control
+ messages are used when appropriate.
+
+All UEs are GPRS-only (doesn't support EGPRS)::
+ No throughput loss, since all data and control blocks use GPRS.
+
+Some UEs are GPRS-only, some EGPRS::
+In general EGPRS capable UEs will use EGPRS, and GPRS-only UEs will use GPRS,
+with some restrictions affecting throughput of EGPRS capable UEs:
+- Whenever a GPRS-only MS is to be polled to send uplink data to PCU, then a
+downlink RLCMAC block encoded in GMSK must be sent, which means that if the
+scheduler selects a EGPRS MS for downlink on that block it will force sending of
+data with MCS1-4 (if it's new data, if it's a retransmission it cannot be
+selected since MCS from original message cannot be changed). In the worst case
+if no control block needs to be sent or no new data in MCS1-4 is available to
+send, then an RLCMAC Dummy Block is sent.
+- For synchronization purposes, each MS needs to receive an RLCMAC block which
+it can fully decode at least every 360ms, which means the scheduler must enforce
+a downlink block in CS1-4 every 360ms, that is, every 18th RLCMAC block. In
+general this is not a big issue since anyway all control RLCMAC blocks are
+encoded in CS1, so in case any control block is sent from time to time it's
+accomplised and there's no penalty. However, if only EGPRS Downlink Data is sent
+over that time frame, then the scheduler will force sending a Rlcmac Dummy
+Block.
+
+
 
 WARNING: EPGRS functionality is highly experimental at the time of this
 writing.  Please only use if you actively would like to participate in

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/21943
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: I7b205f5cab5862058a408f628925beb9f0f60a92
Gerrit-Change-Number: 21943
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210105/8e2d25ae/attachment.htm>


More information about the gerrit-log mailing list