Subject: [manet-dlep-rg] DLEP metrics for 802.11 and Software Defined Radios

From: Henning Rogge <[email-masked]>
Date: Tue, 13 Aug 2013 14:23:11 +0200

Hi,

I had a meeting with our local Software Defined Radio group today about 
DLEP metrics, so I can finally give you a list of metrics I collected 
both from the Linux Mac802.11 stack and from suggestions of our SDR group.

I sorted the list into 2 times 2 categories, split into "per radio vs. 
per neighbor" and "information/statistics vs. radio metrics".

Looking forward for your comments about the list.

---------------------------

PER RADIO-INTERFACE METRICS:
############################

Statistics/Information Metric:
------------------------------

- Network identifier (ascii string)
	String representation of the network the radio is connected to

- Resources (dimensionless 0-100)
	as defined in DLEP

- Supported bitrates (array in bit/s)
	Array of available bitrates for outgoing traffic

Radio/Linklayer Metrics:
------------------------

- Bandwidth (Hz)
	Wide of used frequency spectrum
	(IEEE 802.11 would be typically 20 MHz, sometimes 40 or 80 MHz)

- Channel active time (ms)
	Total time this radio link have been active

- Channel busy time (ms)
	Total time the channel was busy,
	either by data transmissions or energy/noise detection

- Channel receive time (ms)
	Total time this radio interface received data

- Channel transmit time (ms)
	Total time this radio interface sent data

- Channel utilization (dimensionless 0-100)
	percentage of the channel currently being used

- Frequency (Hz)
	Channel mid frequency
	(Range/array of frequencies for channel hopping?)

- Transmission power (dBm)
	Outgoing minimum/maximum transmission power

PER STATION/DESTINATION METRICS
###############################

Statistics/Information Metric:
------------------------------

- Last active (ms)
	Time since station was seen active

- Link Status (heard, silent, symmetric, lost)
	Status of link to neighbor. "silent" means neighbor is there
	but cannot currently send data.

- Rx bitrate (bit/s)
	Bitrate of last incoming packet

- Rx frames (dimensionless)
	Total number of incoming packets
	
- Rx loss (dimensionless)
	Total number of lost incoming frames
	(e.g. wrong checksum or failed forward error correction)

- Tx bitrate (bit/s)
	Current outgoing bitrate

- Tx frames (dimensionless)
	Total number of outgoing (linklayer) frames
	(without retries)

- Tx loss (dimensionless)
	Total number of failed transmitted (linklayer) frames

- Tx retries (dimensionless)
	Total number of retransmitted (linklayer) frames

Radio/Linklayer Metrics:
------------------------

- Expected Transmission Time (ms)
	Expected delay from sending the data arriving at the local radio
	to the moment the data leaves the neighbor radio
	(whats about packet size related transmission time?)

- Power constraint (dBm)
	Maximum outgoing transmission power

- Rx Signal strength (dBm)
	Current (averaged?) incoming transmission strength

- Rx Signal to Interference and Noise Ratio (dB)
	Current (averaged?) relation between
		signal and interference/noise of a neighbor

- Rx biterror rate (dimensionless, 10^0 to 10^-15 ?)
	Current (averaged?) biterror rate of the link
	(e.g. from forward error correction)

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Aug 2013 15:45:13 +0200

Below my input on cellular networks and L-band satcom terminals.
Maybe this needs some discussion, how to deal with it.

Teco

=====

DLEP and 2G/3G/4G Cellular modems

1. Topology
In a cellular topology, links can have single RF hop to a router connected 
to the (high speed) backbone network, or a multi RF hop to a router connected 
to the backbone via another WAN link. Typically, the cellular modem is not aware 
of the non-first hop in the links. In the multi-hop case, the topology looks 
like hub and spoke. Traffic is directed to the backbone, then to the router via 
the other RF lag. 
The link metrics for the cellular link can be used as metrics for a (related)
default gateway or as metrics for a (related) tunnel to a remote neighbor.

2. Interface to cellular modem link
The interface of 3GPP cellular modems is re-using the ITU-T V.250 TE-TA
"AT command" interface. Commands specific for the cellular network are 
specified in 3GPP TS 27.007 and have a "+C" prefix. Many extensions are defined.
For this overview, Sierra Wireless reference material is used.

2. Network technology 
The modem is aware of the current network technology supported by the modem 
and of the network technology supported by the network.
This information is available from the AT*CNTI=<n> command.
Modern name for network technology is Radio Access Technology (RAT). 
List of network technologies: 
- “GSM” 
- “GPRS” 
- “EDGE” 
- ”UMTS” 
- “HSDPA” 
- “HSUPA” 
- “HSDPA / HSUPA” 
- “HSPA+” 
- “LTE”
- “Unknown” 
Maybe more is on its way (e.g. LTE-Advanced).

From the AT!SELRAT=<ratInd> command, the modem can be instructed to set the 
desired RAT configuration. List of <ratInd>
(RAT configuration index): 
- 00=Automatic 
- 01=UMTS 3G only 
- 02=GSM 2G only 
- 03=UMTS 3G preferred 
- 04=GSM 2G preferred 
- 05=GSM and UMTS only 
- 06=LTE only 
- 07=GSM, UMTS, LTE 
- 08=CDMA, HRPD, GSM, UMTS, LTE 
- 09=CDMA only 
- 0A=HRPD only 
- 0B=hybrid CDMA/HRPD 
- 0C=CDMA, LTE 
- 0D=HRPD, LTE 
- 0E=CDMA, HRPD, LTE 
- 0F=CDMA, GSM, UMTS 
- 10=CDMA, HRPD, GSM, UMTS

3. Signal quality 
The modem can report the received signal quality, with received signal 
strength indication <rssi> and channel bit error rate <ber>. 
This information  is available from the AT+CSQ command which returns a
RSSI value between 0 and 31 (-113dBm or less to -51dBm or better),
BER is in percentage, 99 means unknown.
Note: it seems the Sierra Wireless cards do not report a known BER.

4. Received signal code power 
For CDMA systems (like UMTS), received signal code power (RSCP) is the 
power measured by a receiver, on a particular physical communication 
channel. 
This information is available from the AT+RSCP command.
Up to three values can be available per cell carrier (for up to three cells).
Values are signed integers, from -120 to -20dBm.

5. Total Energy per chip per power density 
For CDMA systems (like UMTS), Ec/Io is the ratio of the received energy per 
chip (= code bit) and the interference level, usually given in dB.
This information is available from the AT+ECIO command.
Up to three values can be available per cell carrier (for up to three cells).
Values are signed floating point, from -31.5 to 0dBm.

6. Average WCDMA power level over time period 
For CDMA systems (like UMTS), received Average WCDMA power level over 
time period can be reported.
This information is available (after enabling with the AT+POWER=1) from the
AT+POWER? command. 
Up to two values can be available, for main and diversity antenna, for 
up to two carriers. Values are signed integer, from -120 to -20dBm.

7. Packet Data Protocol (PDP) context 
The 3GPP networks support different virtual channels on a link. This is 
to be used for for example different protocols (IPv4 or IPv6), QoS 
profiles and header or data compression schemes. 
For QoS control, traffic flow templates with QoS profiles can be set up 
with a protocol defined in 3GPP TS 27.007.

8. Data throttling by provider
Mobile network operators may shape user data rate depending on subscription 
and / or used data volume in predefined period (e.g. monthly bundle). 
Information on such shaping is not available to the modem.

9. Probing
As an alternative approach, the router could perform probing towards a central
server or to neighbors. Probing would provide RTT and some indication on 
congestion and available data rate (for probed DSCP class). 

Summary for cellular modems and DLEP link metrics 
 - For a given radio, the maximum data rate that the modem supports could be 
   provided. In addition, the used network technology / radio access technology 
   information could be used for the current data rate. 
 - The actual current data rate is typically a lower value caused by current RF 
   propagation conditions. The maximum rate for the Radio Access Technology 
   could be adjusted based on a translation from signal quality, received signal 
   code power, total Energy per chip per power density and optionally average 
   WCDMA power level over time period. 
 - The to_be_defined shared data rate is highly dependent on the unknown number 
   of other mobile devices and usage patterns in the area. There is no 
   information on the link utilisation nor on throttling by operator. As a 
   result, available capacity for the mobile device is largely unknown.
 - For guaranteed throughput, 3GPP has defined protocols and this is implemented 
   in current radio's. I'm not experienced in how mobile network operators 
   support this.

=======

DLEP and (L-band) satellite terminals

1. Reuse of cellular networks technology
L-band satellite systems like Inmarsat BGAN and Thuraya IP / XT are based on 
cellular network technology. However, the 3GPP TS 27.007 AT command interface 
is typically not available on satcom terminals. Therefore it is difficult to 
get the link characteristics out of the modem.
In some cases, a telnet of http interface is provided and using an proprietary 
API or even webpage screen scraping, information can be gathered.
Provided information would be the link state and received signal quality.
In some systems, QoS profiles can be configured and IP streaming services 
can be set up.

2. Other THDMA based satellite terminals
Nowadays TDMA technology is available for many other types of satellite 
communications. Many proprietary systems are on the market. For interfacing 
with standardized products, ETSI DVB-RCS would be of interest. As far as I
know, no user network interface is defined providing information for the satcom 
link.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Aug 2013 08:09:55 +0200

Some comments inline...

> - 10=CDMA, HRPD, GSM, UMTS

Not easy to do in DLEP... maybe some optional "technology identifier" 
and a technology specific "technology transmission mode identifier" ?

> Note: it seems the Sierra Wireless cards do not report a known BER.

Biterror-rate in percent doesn't make sense.

Even a BER of 1% means that the channel is unusable. The chance to get a 
single 1500 byte packet over such a channel without a flipped bit would 
be practically zero (1E-53).

Theoretically this could be the chance of at least a single bit-error in 
a complete layer-2 frame, but this would be frame-length dependent.

Can you check again, maybe this value is just the negative exponent of 
the BER similar to the encoding the radio specialists at our institute 
suggested?

> 6. Average WCDMA power level over time period

Looks like using dBm for signal/SNR related things is okay.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 16 Aug 2013 17:04:14 +0200

Op 15 aug. 2013, om 08:09 heeft Henning Rogge <[email-masked]> het volgende geschreven:
> Even a BER of 1% means that the channel is unusable. The chance to get a single 1500 byte packet over such a channel without a flipped bit would be practically zero (1E-53).
> 
> Theoretically this could be the chance of at least a single bit-error in a complete layer-2 frame, but this would be frame-length dependent.
> 
> Can you check again, maybe this value is just the negative exponent of the BER similar to the encoding the radio specialists at our institute suggested?

BER information would not apply to user data transport, as it is measured before FEC or channel decoding.

The to_be_reported BER is using GSM 08.05 RXQUAL encoding. See chapter 8.2
http://www.etsi.org/deliver/etsi_gts/05/0508/05.01.00_60/gsmts_0508v050100p.pdf
or more recent spec: 3GPP R12. 
http://www.3gpp.org/ftp/Specs/archive/45_series/45.008/45008-c00.zip

8 codepoints, BER values 0.14%, 0.28%, 0.57%, 1,13%, 2,26%, 4.53%, 9.05%, 18.10%.

I'll verify with LTE cards, maybe these provide something better than unknown.

Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 16 Aug 2013 17:13:49 +0200

> I'll verify with LTE cards, maybe these provide something better than unknown.

FYI, the 3GPP R12 +CSQ spec:
http://www.3gpp.org/ftp/Specs/archive/27_series/27.007/27007-c10.zip

<3GPP spec>

8.5         Signal quality +CSQ

Table 64: +CSQ action command syntax

Command	Possible response(s)
+CSQ	+CSQ: <rssi>,<ber>
	+CME ERROR: <err>
+CSQ=?	+CSQ: (list of supported <rssi>s),(list of supported <ber>s)

Description

Execution command returns received signal strength indication <rssi> and channel bit error rate <ber> from the MT. Refer subclause 9.2 for possible <err> values.

Test command returns values supported as compound values.

Defined values

<rssi>: integer type
0        ‑113 dBm or less
1        ‑111 dBm
2...30  ‑109... ‑53 dBm
31      ‑51 dBm or greater
99      not known or not detectable

<ber>: integer type; channel bit error rate (in percent)
0...7   as RXQUAL values in the table in 3GPP TS 45.008 [20] subclause 8.2.4
99      not known or not detectable

Implementation
Optional.

</3GPP spec>

Teco

---

From: Henning Rogge <[email-masked]>
Date: Thu, 29 Aug 2013 10:53:56 +0200

> I'll verify with LTE cards, maybe these provide something better than unknown.

I think this a point we have to clarify... do we want biterror rate 
before or after things like FEC?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 29 Aug 2013 11:09:03 +0200

Op 29 aug. 2013, om 10:53 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> I think this a point we have to clarify... do we want biterror rate before or after things like FEC?

On cellular networks, L2 provides reliability. Not important if it is FEC or retransmit.

The info I provided was an inventory. Next steps would be to summarize all we've got and merge into the basic / mandatory set of metrics. Then verify if current DLEP draft needs modification.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 29 Aug 2013 17:14:31 +0000

Gentlemen, 

Just FYI, I don't have the DLEP-05 as promised for today. Some health issues got in the way; it'll be a few more days. 

…sigh. The slings and arrows of getting older… ;-)

Regards,
Stan