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

From: Henning Rogge <[email-masked]>
Date: Mon, 2 Sep 2013 09:07:18 +0200

On 08/14/2013 03:45 PM, Teco Boot wrote:
> 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.

I thought about the Error Rate thing again and I am still sure this 
cannot be right.

If BER (bit error rate) is a non-fractional percentage, the minimum 
bit-error rate would be 1%...

Even if a packet is just 16 bytes, this would mean only 25% of the 
packets will have no bit error.

I think a percentage value makes only sense if its "packet error rate", 
the chance that there is at least one non-correctable bit error in the 
packet.

The bit error rate needs to be 1E-5 or better to be useful.

My co-workers from the radio/sdr department asked for something like "2 
to the power of a negative integer" as a bit error representation.

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: Mon, 2 Sep 2013 13:08:25 +0200

Op 2 sep. 2013, om 09:07 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> I thought about the Error Rate thing again and I am still sure this cannot be right.
> 
> If BER (bit error rate) is a non-fractional percentage, the minimum bit-error rate would be 1%...
> 
> Even if a packet is just 16 bytes, this would mean only 25% of the packets will have no bit error.
> 
> I think a percentage value makes only sense if its "packet error rate", the chance that there is at least one non-correctable bit error in the packet.
> 
> My co-workers from the radio/sdr department asked for something like "2 to the power of a negative integer" as a bit error representation.
> 

Did you see my response on Aug 16th?
3GPP spec:
<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.

FEC can easily correct BER >1%. 
I am aware of a military radio that reduce Tx power to have ~1% packer error rate at first transfer and repair with ARQ. BER before FEC would be much, much higher than 1%. Great for LPD/LPI. (OK, RTS/CTS on signaling channel is at max power)

Teco

> _______________________________________________
> manet-dlep-rg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg

---

From: Henning Rogge <[email-masked]>
Date: Mon, 2 Sep 2013 13:20:52 +0200

> I am aware of a military radio that reduce Tx power to have ~1% packer error rate at first transfer and repair with ARQ. BER before FEC would be much, much higher than 1%. Great for LPD/LPI. (OK, R…

I am not sure its worth to have a TLV for bit error rate after forward 
error correction. Every bit error after FEC will be a packet loss 
anyways because of a checksum on an OSI layer.

But if bit error rate before FEC is available, it can tell the router 
something about the reliability of the link before the connection (on 
layer 2/3 gets packet loss.

Henning Rogge

---

From: jpmacker <[email-masked]>
Date: Mon, 2 Sep 2013 10:47:55 -0400

there is sometimes value in letting corrupted payloads through but partial checksum are used .. i wonder if there are radios that act like udp lite.

but i do agree ber in integer percentage is not useful for large MTUs.  packet error rate is generally more useful and can sometimes not be directly calculated from ber but it can also be orders of magnitude off.

can we better define the flow here for discussion, modulation is also often changed to alter ber not just coding?

also some radios have better packet error statistics with cbr rather than burst traffic due to styles of channel contention and adaptive QoS approaches for various environments.  makes all of this more complex that one would like.

Sent from my iPad

On Sep 2, 2013, at 7:20 AM, Henning Rogge <[email-masked]> wrote:

> I am not sure its worth to have a TLV for bit error rate after forward error correction. Every bit error after FEC will be a packet loss anyways because of a checksum on an OSI layer.
> 
> But if bit error rate before FEC is available, it can tell the router something about the reliability of the link before the connection (on layer 2/3 gets packet loss.
> 
> Henning Rogge
> 
> 
> --

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 3 Sep 2013 08:47:23 +0000

I don't believe BER is a useful 'core' metric.  The underlying error rate affects latency and data rates, but given the number of different ways radios may cope with bit-errors, reporting the rate to the router will, IMHO, result in routers making foolish assumptions.

I vote to drop BER as a core metric - if a vendor wants to report it as an extension that is fine by me.

@Teco: The Huawei 3G dongles I've looked at always report a BER as 99, so, given your experience with Sierra Wireless, I reckon that most manufacturers opt not to implement it.  (I wonder if they use the same chipset internally)

Rick Taylor

> -----Original Message-----
> From: [email-masked] [mailto:manet-dlep-rg-
> [email-masked]] On Behalf Of jpmacker
> Sent: 02 September 2013 15:48
> To: Henning Rogge
> Cc: [email-masked]; Teco Boot
> Subject: Re: [manet-dlep-rg] DLEP metrics for 802.11 and Software Defined
> Radios
>
> there is sometimes value in letting corrupted payloads through but partial
> checksum are used .. i wonder if there are radios that act like udp lite.
>
> but i do agree ber in integer percentage is not useful for large MTUs.
> packet error rate is generally more useful and can sometimes not be
> directly calculated from ber but it can also be orders of magnitude off.
>
> can we better define the flow here for discussion, modulation is also
> often changed to alter ber not just coding?
>
> also some radios have better packet error statistics with cbr rather than
> burst traffic due to styles of channel contention and adaptive QoS
> approaches for various environments.  makes all of this more complex that
> one would like.
>
> Sent from my iPad
>
> On Sep 2, 2013, at 7:20 AM, Henning Rogge
> <[email-masked]> wrote:
>
> >> I am aware of a military radio that reduce Tx power to have ~1% packer
> error rate at first transfer and repair with ARQ. BER before FEC would be
> much, much higher than 1%. Great for LPD/LPI. (OK, RTS/CTS on signaling
> channel is at max power)
> >
> error correction. Every bit error after FEC will be a packet loss anyways
> because of a checksum on an OSI layer.
> >
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: Teco Boot <[email-masked]>
Date: Tue, 3 Sep 2013 11:20:28 +0200

I just reported what cellular radios can/may report.
We use the +CSQ_RSSI right now, for feedback to user and gateway selection (first *CNTI, then CSQ RSSI). RSSI cannot be trusted that much. We take the better_than_nothing approach.

All:
I think we achieved out first milestones. Maybe define our next steps. Make list of what we have? Then define what the core/optional metrics would be? Define handling "order"? Discussion of flow control and how to deal with multiple queues in the radio and multi-hop L2 links?

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 3 Sep 2013 09:38:09 +0000

I agree with Teco: I think we achieved a great deal so far with the outline documents, thank you everyone, they are excellent.

I suggest we split the discussion now into a few orthogonal topics:

1) Reporting metrics in multi-hop radio networks.

2) Reporting metrics in multi-queue environments.

3) Capturing metric meta-information using the TLV format - Directionality, link or device, vendor extensions, etc... (I have some ideas here)

4) Rationalising DLEP messages into acknowledged messages, signals, events, etc, just so we have some clarity about reliability between radio and router. (I posted to the manet list about this, but I can reformat and repost here if people want)

5) Link characteristic requests - They seem to be a 'catch all' for functionality some would like to see in DLEP with no better home.  I believe there might be some scope for rationalising/formalising this class of messages.

Anyone have any better/extra ideas?

Rick Taylor

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Sep 2013 15:20:25 +0000

Rick/All - 

Well, I'm concerned about the notion that we "split the discussion now into a few orthogonal topics". I thought the whole purpose of the DT was to get a common (I'd read that as non-orthogonal) set of metrics. So going into orthogonal topics scares the daylights out of me. 

That being said, I've got comments on the specific topics inline. 

> 1) Reporting metrics in multi-hop radio networks.

Again, at least to me, this boils down to some text that says "multi-hop wireless environments MUST (or SHOULD) report metrics as an 'end-to-end' value. That is, the metric values MUST (or SHOULD) accurately represent the whole of the multiple hops between the routers." If there's another approach, then I'm open to it.

> 2) Reporting metrics in multi-queue environments.

Given our desire to handle multiple queues, I think this is a good discussion topic. 

> 3) Capturing metric meta-information using the TLV format - Directionality, link or device, vendor extensions, etc... (I have some ideas here)

Huh? Meta-information? You're not working for the NSA, are you? ;-)

> 4) Rationalising DLEP messages into acknowledged messages, signals, events, etc, just so we have some clarity about reliability between radio and router. (I posted to the manet list about this, but…

I'm lost here as well. Are you saying that DLEP is irrational? ;-)

> 5) Link characteristic requests - They seem to be a 'catch all' for functionality some would like to see in DLEP with no better home.  I believe there might be some scope for rationalising/formalis…

And again, this completely loses me. LCR is a request from the router to the radio to "give me more", or "give me better" - more bandwidth, better (less) latency. That's about it. I'm not seeing the catch-all.

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Sep 2013 15:46:13 +0000

> My co-workers from the radio/sdr department asked for something like "2 to the power of a negative integer" as a bit error representation.

I've always seen BER expressed as "10 to the power of a negative integer", so I'd be reluctant to have DLEP express it as anything else. 

That being said, I'm struggling with reporting BER at all. At least for the radios I've dealt with, BER is meaningless. The radio is watching BER closely, and is changing modulation techniques when BER gets into what the radio thinks is an unacceptable range. So if we're going to *require* BER (e.g. make it mandatory) for all implementations, how would a radio report that "BER doesn't matter in my case"?

Regards,
Stan

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 3 Sep 2013 15:52:48 +0000

> From: Stan Ratliff (sratliff) [mailto:[email-masked]]
>
> Well, I'm concerned about the notion that we "split the discussion now
> into a few orthogonal topics". I thought the whole purpose of the DT was
> to get a common (I'd read that as non-orthogonal) set of metrics. So going
> into orthogonal topics scares the daylights out of me.

I meant orthogonal in the sense of non-overlapping, perhaps a poor choice of word ;-)

> > I agree with Teco: I think we achieved a great deal so far with the
> outline documents, thank you everyone, they are excellent.
> >
> Again, at least to me, this boils down to some text that says "multi-hop
> wireless environments MUST (or SHOULD) report metrics as an 'end-to-end'
> value. That is, the metric values MUST (or SHOULD) accurately represent
> the whole of the multiple hops between the routers." If there's another
> approach, then I'm open to it.

I 100% agree, but, the topic keeps coming up again and again, are we *absolutely* sure this is a) possible, b) covers corner cases?  I'm looking at John and Bow-Nan for advice here.  (The SHOULD worries me)

> >
> > 3) Capturing metric meta-information using the TLV format -
> Directionality, link or device, vendor extensions, etc... (I have some
> ideas here)
>

I couldn't say if I was... ;-)

We have stated before that a metric TLV needs to encode directionality, link or device, etc.  I am proposing extending the T in TLV to 16bits and having a standard encoding in those bits to cover it, e.g.

+------------+-----------+---------------+
| Type code  | Direction |  Vendor code  |
|  8 bits    |  2 bits   |    6 bits     |
+------------+-----------+---------------+

Direction would be: 00 - Modem metric, 01 Upstream, 10 Downstream, 11 Bidirectional.

I can imagine this starting a discussion of its own, so I mentioned it.

>
> >
> > 4) Rationalising DLEP messages into acknowledged messages, signals,
> events, etc, just so we have some clarity about reliability between radio
> and router. (I posted to the manet list about this, but I can reformat and
> repost here if people want)
>

Not all of it ;-)

As I've said before, as part of the wider reliability/TCP discussion, DLEP messages fall into 1 of several classes:

1) In-order, reliable, require acknowledgement = COMMANDS (Link Ch Req)
2) In-order, reliable, optional or no ack. = EVENTS (Neighbour Up)
4) Reliable, most-recent applies, no ack. = SIGNALS (Metrics Change)
5) Unreliable, e.g. Discovery messages.

As part of a review of draft-0X, I believe it would be useful to check that all DLEP messages fall into these categories, and for the sake of those not using TCP, the explicit delivery requirements are listed.

I'll repost my previous email to this list for clarification.

> >
> > 5) Link characteristic requests - They seem to be a 'catch all' for
> functionality some would like to see in DLEP with no better home.  I
> believe there might be some scope for rationalising/formalising this class
> of messages.
>
> And again, this completely loses me. LCR is a request from the router to
> the radio to "give me more", or "give me better" - more bandwidth, better
> (less) latency. That's about it. I'm not seeing the catch-all.

I just have vague recollections of various requests for functionality being pushed aside with the phrase 'Oh that can be a link characteristic request'.  Have the final set of characteristics been defined?  Are they extensible?  I assume they will continue to be metric-style TLVs?  Or have I confused Link characteristic requests with other router-to-radio messages in my head... not sure, so I asked...

Rick Taylor

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 3 Sep 2013 15:55:12 +0000

> [email-masked]] On Behalf Of Stan Ratliff (sratliff)
>
> That being said, I'm struggling with reporting BER at all. At least for
> the radios I've dealt with, BER is meaningless. The radio is watching BER
> closely, and is changing modulation techniques when BER gets into what the
> radio thinks is an unacceptable range. So if we're going to *require* BER
> (e.g. make it mandatory) for all implementations, how would a radio report
> that "BER doesn't matter in my case"?
>

+1

As I've said before, BER seems non-core to me.

Rick Taylor

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Sep 2013 16:08:02 +0000

> I 100% agree, but, the topic keeps coming up again and again, are we *absolutely* sure this is a) possible, b) covers corner cases?  I'm looking at John and Bow-Nan for advice here.  (The SHOULD wo…

I'm OK with making it a MUST. It's just that when I do that, I usually get "clocked" from some direction, so I flinched… ;-) And I really don't see another alternative. For example, if at Layer 2 you have:
Router---Radio A---------Radio B---------Radio C-----Router

and the bandwidth from A to B is 16Mbps, but the Bandwidth from B to C is 8Mbps, then the routers HAVE to receive metric updates saying the bandwidth from router-to-router is 8Mbps…. And in the cases where multiple stations feed into a single radio (the "Bow-Tie topology" we keep talking about), it's the radio's responsibility to accurately provision the critical resource (the RF link at the middle of the Bow Tie).

> We have stated before that a metric TLV needs to encode directionality, link or device, etc.  I am proposing extending the T in TLV to 16bits and having a standard encoding in those bits to cover i…

Ahhh, OK. From what I've seen, I don't know that a TLV parsing scheme would fly. I'm looking at this more as an "enumeration issue" - that being, we assign TLVs for "Receive CDR", and "Transmit CDR". Etc etc etc (ad nauseum) until we work our way through the mandatory metrics. 

> I'll repost my previous email to this list for clarification.

OK, that makes sense. Perhaps it's me that's irrational…. (don't answer that). :-) 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Sep 2013 07:41:37 +0200

> I've always seen BER expressed as "10 to the power of a negative integer", so I'd be reluctant to have DLEP express it as anything else.
"10 to the power of negative integer" would be fine too.

> That being said, I'm struggling with reporting BER at all. At least for the radios I've dealt with, BER is meaningless. The radio is watching BER closely, and is changing modulation techniques when…

I just ask because our SDR research group considers this value important 
for their projects. Most likely its an encoding we should push to a 
companion document, because its not one of the "essentially to integrate 
into your radio" things.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Sep 2013 07:44:43 +0200

On 09/03/2013 06:08 PM, Stan Ratliff (sratliff) wrote:
>> +------------+-----------+---------------+ | Type code  | Direction
>> |  Vendor code  | |  8 bits    |  2 bits   |    6 bits     |
> Ahhh, OK. From what I've seen, I don't know that a TLV parsing scheme
> would fly. I'm looking at this more as an "enumeration issue" - that
> being, we assign TLVs for "Receive CDR", and "Transmit CDR". Etc etc
> etc (ad nauseum) until we work our way through the mandatory
> metrics.

I think enumeration should be enough for nearly all usecases, especially 
if we allocate a "vendor specific TLV" area.

Adding a "vendor code" to all metric types feels like an invitation to 
allow every vendor to do "his" variant of the standard metrics, which 
would defeat interoperability.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 4 Sep 2013 09:08:35 +0000

> [email-masked]] On Behalf Of Henning Rogge
> Sent: 04 September 2013 06:45
> To: [email-masked]
> Subject: Re: [manet-dlep-rg] Next milestones
>

I was looking to encode some semantics into the enumeration, nothing more,
e.g.:

enum Metrics
{
        Latency_Down = 0x71,
        Latency_Up = 0x72,
        Latency_Both = 0x73,  <-- Is this needed?

        Maximum_Data_Rate = 0x80 <-- This is a modem metric
}

Do we need to differentiate between directional metrics for asymmetric links and symmetric link metrics?  Surely the metric is 'Latency' and the update reports the direction that applies to the metric: Up, Down, Symmetric?

> would defeat interoperability.

The vendor code is probably a mistake, but I still have concerns that 8bits might be too small for metric types.

My alternate thought was reserve some TLVs at the end of the space, e.g.

enum Metrics
{
        Experimental = 0xF8..0xFE,
        Vendor_extension = 0xFF
}

And 'vendor extension' metric requires an additional 8 bits to encode what they want?

Hmmm... this is definitely a topic worth exploring.

Rick Taylor

---

From: "Dowdell, John" <[email-masked]>
Date: Wed, 4 Sep 2013 09:39:34 +0000

<snip>

> That being said, I'm struggling with reporting BER at all. At least for the radios I've dealt with, BER is meaningless. The radio is watching BER closely, and is changing modulation techniques when…

I just ask because our SDR research group considers this value important for their projects. Most likely its an encoding we should push to a companion document, because its not one of the "essentially to integrate into your radio" things.

Henning Rogge

-------------------
I think we are faced with two sorts of radios here, the newer, more intelligent variety, and the older and less intelligent.

The newer radios are smarter, think for themselves, and are adaptive in their modulation and (possibly) FEC. As Stan points out, reporting BER has no meaning because the radio is thinking about how to improve the path.

The older radios think less for themselves and may report BER, but, as Teco reports [1], the BER field may simply be fixed at a constant.

It does occur to me that BER/RSSI is useful as a deciding factor if you have two similar radios to choose from in the cellular topology but otherwise I am not sure it is useful.

John

[1] http://www.ietf.org/mail-archive/web/manet-dlep-rg/current/msg00002.html

---

From: "Dowdell, John" <[email-masked]>
Date: Wed, 4 Sep 2013 09:48:46 +0000

> >> On Sep 3, 2013, at 5:38 AM, "Taylor, Rick"
> <[email-masked]>
> >> wrote:
> >>
> > I 100% agree, but, the topic keeps coming up again and again, are we
> *absolutely* sure this is a) possible, b) covers corner cases?  I'm
> looking at John and Bow-Nan for advice here.  (The SHOULD worries me)
>
> I'm OK with making it a MUST. It's just that when I do that, I usually
> get "clocked" from some direction, so I flinched... ;-) And I really
> don't see another alternative. For example, if at Layer 2 you have:
> and the bandwidth from A to B is 16Mbps, but the Bandwidth from B to C
> is 8Mbps, then the routers HAVE to receive metric updates saying the
> bandwidth from router-to-router is 8Mbps.... And in the cases where
> multiple stations feed into a single radio (the "Bow-Tie topology" we
> keep talking about), it's the radio's responsibility to accurately
> provision the critical resource (the RF link at the middle of the Bow
> Tie).
>

Completely agree with making this a MUST when the radio and router are loosely coupled, that is the radio and router are black boxes to each other. In the case where the radio and router are tightly coupled, the decision logic can be distributed between router and radio, but I believe that is not what we are about here.

John

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 4 Sep 2013 14:05:20 +0000

>        Maximum_Data_Rate = 0x80 <-- This is a modem metric

Interesting. To the wider group, can we do that? I figured the actual TLV assignments would be "punted" to IANA. 

> Do we need to differentiate between directional metrics for asymmetric links and symmetric link metrics?  Surely the metric is 'Latency' and the update reports the direction that applies to the met…

We can definitely do "Transmit", "Receive", and "Symmetric" (I changed your names to avoid confusing myself with 'Neighbor Up' and 'Neighbor Down'). Or, I can plop some text into the document that says "In the case of symmetric links, implementations MUST set the 'Transmit' and 'Receive' metrics to the same value." Some will probably see that as a cop-out, but it's easier to type… ;-)

> The vendor code is probably a mistake, but I still have concerns that 8bits might be too small for metric types.

I could easily bump the TLV up to 16 bits...

> And 'vendor extension' metric requires an additional 8 bits to encode what they want?

That's one approach. If the type is bumped to 16 bits, then we just reserve a chunk of that TLV space….

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Sep 2013 22:37:36 +0200

Op 3 sep. 2013, om 18:08 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> and the bandwidth from A to B is 16Mbps, but the Bandwidth from B to C is 8Mbps, then the routers HAVE to receive metric updates saying the bandwidth from router-to-router is 8Mbps….

Probably < 8Mbps, when there is time domain duplexing. 

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 4 Sep 2013 21:09:50 +0000

> Probably < 8Mbps, when there is time domain duplexing. 

Fair enough… ;-)  I guess I SHOULD have said "it's the radio's problem"…

Stan