Subject: [Detnet] DetNet Use Case Statements - Transport contrib to RF error +/- 2PPB (2ns)

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 3 Jun 2016 20:14:18 +0000

Statement:
Transport contrib to RF error +/- 2PPB (2ns)

Text from (Cellular Radio) Use Case:
Transport link contribution to radio frequency error:
+-2 PPB. This value is considered to be "available" for the Fronthaul link out of the total 50 PPB budget reserved for the radio interface. Note: the reason that the transport link contributes to radio frequency error is as follows. The current way of doing Fronthaul is from the radio unit to remote radio head directly. The remote radio head is essentially a passive device (without buffering etc.) The transport drives the antenna directly by feeding it with samples and everything the transport adds will be introduced to radio as-is. So if the transport causes additional frequency error that shows immediately on the radio as well.

Discussion:
The reason I am bringing this up is that "2PPB" (assuming this is a time error value) seems like a small value, i.e. 2 nanoseconds (2 out of 10^9), which seems smaller than the nominally millisecond-range values the use cases "typically" discuss.   Is there anything in DetNet architecture that affects anything at this fine of a degree of timing? In other words, does this need to be considered in (or guaranteed by) DetNet, and if not, should this statement be dropped from the use case, or somehow qualified that it is beyond scope of DetNet to guarantee this kind of timing?

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 7 Jun 2016 13:52:41 -0700

Hi Ethan,

I would response similarly as to the delay accuracy question. While the
numbers are ugly it is imho good for people to realize in what kinds of
environments DetNet might be deployed. In practice the system level
requirement is the one that defines the acceptable boundaries (e.g., 50ppb)
and the final transport requirements are a moving target at the moment. The
number shown here is from the pathetic end of the spectrum. I am tempted to
say that it is beyond Detnet to guarantee this kind of timing requirement.
The burden is more put on the time distribution solution and all the tweaks
needed in that domain to guarantee desired error boundaries.

- JOuni

On Fri, Jun 3, 2016 at 1:14 PM, Grossman, Ethan A. <[email-masked]> wrote:

> +-2 PPB. This value is considered to be "available" for the Fronthaul link
> out of the total 50 PPB budget reserved for the radio interface. Note: the
> reason that the transport link contributes to radio frequency error is as
> follows. The current way of doing Fronthaul is from the radio unit to
> remote radio head directly. The remote radio head is essentially a passive
> device (without buffering etc.) The transport drives the antenna directly
> by feeding it with samples and everything the transport adds will be
> introduced to radio as-is. So if the transport causes additional frequency
> error that shows immediately on the radio as well.
>
> Discussion:
> The reason I am bringing this up is that “2PPB” (assuming this is a time
> error value) seems like a small value, i.e. 2 nanoseconds (2 out of 10^9),
> which seems smaller than the nominally millisecond-range values the use
> cases “typically” discuss.   Is there anything in DetNet architecture that
> affects anything at this fine of a degree of timing? In other words, does
> this need to be considered in (or guaranteed by) DetNet, and if not, should
> this statement be dropped from the use case, or somehow qualified that it
> is beyond scope of DetNet to guarantee this kind of timing?
>
>
>
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>
>

-- 
Jouni Korhonen, Broadcom Ltd.