Subject: [Detnet] Crosshaul input for consideration in draft-ietf-detnet-use-cases

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 10 Mar 2017 02:21:52 +0100

Hi,

In Seoul we presented draft-bernardos-detnet-crosshaul-requirements-
00.txt as potential input to be considered for "Section 6. Cellular
radio" of draft-ietf-detnet-use-cases. The group agreed that 
contributions from us were welcome to complement/fix the text in the
use cases document.

We have taken -11 version and tried to propose specific changes to the
document. Please find them below for discussion.

----
6.1.1.  Network Architecture

OLD:

Figure 10 illustrates a typical 3GPP-defined cellular network
architecture, which includes "Fronthaul" and "Midhaul" network
segments.  The "Fronthaul" is the network connecting base stations
(baseband processing units) to the remote radio heads (antennas).
The "Midhaul" is the network inter-connecting base stations (or small
cell sites).

NEW:

Figure 10 illustrates a typical 3GPP-defined cellular network
architecture, which includes "Fronthaul", "Midhaul" and "Backhaul"
network segments.  The "Fronthaul" is the network connecting base
stations (baseband processing units) to the remote radio heads
(antennas).  The "Midhaul" is the network inter-connecting base
stations (or small cell sites).  The "Backhaul" is the network or
links connecting the radio base station sites to the network
controller/gateway sites (i.e. the core of the 3GPP cellular
network).
----
6.1.3.  Time Synchronization Constraints

[...]

OLD:

In cellular networks from the LTE radio era onward, phase
synchronization is needed in addition to frequency synchronization
([TS36300], [TS23401]).

NEW:

In cellular networks from the LTE radio era onward, phase
synchronizatio
n is needed in addition to frequency synchronization
([TS36300],
[TS23401]).

Time constraints are also important due to its impact on packet loss.
If a packet is delivered too late, then the packet may be dropped by
the host.
----

----
6.1.4.  Transport Loss Constraints

[...]

OLD:

For packetized Fronthaul and Midhaul connections packet loss may be
caused by BER, congestion, or network failure scenarios.  Current
tools for elminating packet loss for Fronthaul and Midhaul networks
have serious challenges, for example retransmitting lost packets and/
or using forward error correction (FEC) to circumvent bit errors is
practically impossible due to the additional delay incurred.  Using
redundant streams for better guarantees for delivery is also
practically impossible in many cases due to high bandwidth
requirements of Fronthaul and Midhaul networks.  Protection switching
is also a candidate but current technologies for the path switch are
too slow to avoid reset of mobile interfaces.

NEW:

For packetized Fronthaul and Midhaul connections packet loss may be
caused by BER, congestion, or network failure scenarios.  Some
fronthaul functional splits considered by 3GPP require the frame loss
ratio (FLR) to be less than 10E-7 for data traffic and less than
10E-6 for C&M.  Current tools for eliminating packet loss for
Fronthaul and Midhaul networks have serious challenges, for example
retransmitting lost packets and/or using forward error correction
(FEC) to circumvent bit errors is practically impossible due to the
additional delay incurred.  Using redundant streams for better
guarantees for delivery is also practically impossible in many cases
due to high bandwidth requirements of Fronthaul and Midhaul networks.
Protection switching is also a candidate but current technologies for
the path switch are too slow to avoid reset of mobile interfaces.
----

----
6.3.  Cellular Radio Networks Future

[...]

OLD:

o  All form of xHaul networks will need some form of DetNet
   solutions.  For example with the advent of 5G some Backhaul
   traffic will also have DetNet requirements (e.g. traffic belonging
   to time-critical 5G applications).

NEW:

o  All form of xHaul networks will need some form of DetNet
   solutions.  For example with the advent of 5G some Backhaul
   traffic will also have DetNet requirements (e.g. traffic belonging
   to time-critical 5G applications).

o  Different splits of the functionality run on the base stations
   (baseband processing units) and the remote radio heads (antennae)
   could co-exist on the same Fronthaul and Backhaul network.
----

----
6.4.  Cellular Radio Networks Asks

[...]

OLD:

A standard for data plane transport specification which is:

o  Unified among all xHauls (meaning that different flows with
   diverse DetNet requirements can coexist in the same network and
   traverse the same nodes without interfering with each other)

o  Deployed in a highly deterministic network environment

NEW:

A standard for data plane transport specification which is:

o  Unified among all xHauls (meaning that different flows with
   diverse DetNet requirements can coexist in the same network and
   traverse the same nodes without interfering with each other)

o  Deployed in a highly deterministic network environment

o  Capable of supporting multiple functional splits simultaneously,
   including existing Backhaul and CPRI Fronthaul and new modes as
   defined for example in 3GPP.

o  Slicing and Multi-tenancy-capable, supporting: isolating traffic
   (guaranteed QoS) and separating traffic (privacy).

o  Compatible with existing security and synchronization mechanisms,
   such as IEEE1588, IEEE802.1AS.

o  Capable of transporting both in-band and out-band control traffic
   (OAM info, ...).

o  Deployable over multiple data link technologies (e.g., IEEE 802.3,
   mmWave, etc.).
----

Comments are welcome,

Thanks,

Carlos

---

From: Balázs Varga A <[email-masked]>
Date: Fri, 10 Mar 2017 08:18:44 +0000

Hi Carlos,

Some comments and a question for clarification:

> Some fronthaul functional splits considered by 3GPP require the frame loss ratio (FLR)

> to be less than 10E-7 for data traffic and less than 10E-6 for C&M.

Functional split is still under heavy discussion in 3GPP. These numbers are not defined by 3GPP

and may be dependent on discussion results. So I think including them in the use-case draft

may causes confusions.

>    could co-exist on the same Fronthaul and Backhaul network.

I see a terminology issue here mainly due to the fact that future splits and the resulting

network elements are not (yet) defined. Baseband processing units and antenna refers

to legacy technologies, which does not require DetNet and are out-of-scope.

> new proposed bullets …

Do You propose to extend this section with general requirements of the Cellular

Radio Networks? This section focuses on “data plane transport”. I have concerns on

some items of your list and have found some of them not relevant from DetNet

perspective.

Cheers

Bala’zs

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
Sent: Friday, March 10, 2017 2:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Crosshaul input for consideration in draft-ietf-detnet-use-cases

Hi,

00.txt as potential input to be considered for "Section 6. Cellular radio" of draft-ietf-detnet-use-cases. The group agreed that contributions from us were welcome to complement/fix the text in the use cases document.

We have taken -11 version and tried to propose specific changes to the document. Please find them below for discussion.

----

OLD:

Figure 10 illustrates a typical 3GPP-defined cellular network architecture, which includes "Fronthaul" and "Midhaul" network segments.  The "Fronthaul" is the network connecting base stations (baseband processing units) to the remote radio heads (antennas).

The "Midhaul" is the network inter-connecting base stations (or small cell sites).

NEW:

Figure 10 illustrates a typical 3GPP-defined cellular network architecture, which includes "Fronthaul", "Midhaul" and "Backhaul"

network segments.  The "Fronthaul" is the network connecting base stations (baseband processing units) to the remote radio heads (antennas).  The "Midhaul" is the network inter-connecting base stations (or small cell sites).  The "Backhaul" is the network or links connecting the radio base station sites to the network controller/gateway sites (i.e. the core of the 3GPP cellular network).

----

[...]

OLD:

In cellular networks from the LTE radio era onward, phase synchronization is needed in addition to frequency synchronization ([TS36300], [TS23401]).

NEW:

In cellular networks from the LTE radio era onward, phase synchronizatio n is needed in addition to frequency synchronization ([TS36300], [TS23401]).

If a packet is delivered too late, then the packet may be dropped by the host.

----

----

[...]

OLD:

For packetized Fronthaul and Midhaul connections packet loss may be caused by BER, congestion, or network failure scenarios.  Current tools for elminating packet loss for Fronthaul and Midhaul networks have serious challenges, for example retransmitting lost packets and/ or using forward error correction (FEC) to circumvent bit errors is practically impossible due to the additional delay incurred.  Using redundant streams for better guarantees for delivery is also practically impossible in many cases due to high bandwidth requirements of Fronthaul and Midhaul networks.  Protection switching is also a candidate but current technologies for the path switch are too slow to avoid reset of mobile interfaces.

NEW:

For packetized Fronthaul and Midhaul connections packet loss may be caused by BER, congestion, or network failure scenarios.  Some fronthaul functional splits considered by 3GPP require the frame loss ratio (FLR) to be less than 10E-7 for data traffic and less than

10E-6 for C&M.  Current tools for eliminating packet loss for Fronthaul and Midhaul networks have serious challenges, for example retransmitting lost packets and/or using forward error correction

(FEC) to circumvent bit errors is practically impossible due to the additional delay incurred.  Using redundant streams for better guarantees for delivery is also practically impossible in many cases due to high bandwidth requirements of Fronthaul and Midhaul networks.

Protection switching is also a candidate but current technologies for the path switch are too slow to avoid reset of mobile interfaces.

----

----

[...]

OLD:

NEW:

----

----

[...]

OLD:

NEW:

   (OAM info, ...).

   mmWave, etc.).

----

Comments are welcome,

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 13 Mar 2017 17:46:55 +0100

Hi Balázs,

Apologies for the belated reply. Please see in line below.

> and may be dependent on discussion results. So I think including them

This is a fair point. The purpose of this was to provide some exemplary
numbers (which I think are helpful, as provided for other use cases in
the document). Maybe we can rewrite this part a bit so we say
"Different fronthaul functional splits are being considered by 3GPP,
requiring strict frame loss ratio (FLR) guarantees. As one example,
lower layers splits require FLR to be less than 10E-7 for data traffic
and less than 10E-6 for C&M", or something like this. What do you
think?

> to legacy technologies, which does not require DetNet and are out-of-

I see this point. What about rewriting this a bit to avoid the
terminology issue: "Different splits of the functionality run on the
base stations (centralized units) and the on-site units (distributed
units) could co-exist on the same Fronthaul and Backhaul network"?

> some items of your list and have found some of them not relevant from

Sorry, I don't get what your concerns are here, can you elaborate a bit
more?

Thanks,

Carlos

> We have taken -11 version and tried to propose specific changes to
> the document. Please find them below for discussion.
>  
> ----
> synchronizatio n is needed in addition to frequency synchronization
> ([TS36300], [TS23401]).
>

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 14 Mar 2017 08:49:23 +0000

Hi Carlos,

Thanks for the clarifications, some reflections:
- FLR values: there are "multiple low layer splits". I would prefer to add values only if we can refer explicitly to a standard.
- Naming: what is distributed vs. centralized will be network scenario and vendor specific. We should speak more about 
interconnection of functionalities without stating their geographical locations. So I am fine to highlight the "co-existence"
factor just intend to have better terminology.
- Requirements: here the list is about "data plane transport specification". In my view your new bullets are more end2end
architecture specific requirements (e.g., "supporting multiple functional splits simultaneously", "Slicing and 
Multi-tenancy-capable", etc.). These are valid requirements but not the primary targets of DetNet. 

Cheers
Bala'zs

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
Sent: Monday, March 13, 2017 5:47 PM
To: Balázs Varga A <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: Crosshaul input for consideration in draft-ietf-detnet-use-cases

Hi Balázs,

On Fri, 2017-03-10 at 08:18 +0000, Balázs Varga A wrote:
> Functional split is still under heavy discussion in 3GPP. These 
> numbers are not defined by 3GPP and may be dependent on discussion 
> results. So I think including them in the use-case draft may causes 
> confusions.

This is a fair point. The purpose of this was to provide some exemplary numbers (which I think are helpful, as provided for other use cases in the document). Maybe we can rewrite this part a bit so we say "Different fronthaul functional splits are being considered by 3GPP, requiring strict frame loss ratio (FLR) guarantees. As one example, lower layers splits require FLR to be less than 10E-7 for data traffic and less than 10E-6 for C&M", or something like this. What do you think?

> I see a terminology issue here mainly due to the fact that future 
> splits and the resulting network elements are not (yet) defined. 
> Baseband processing units and antenna refers to legacy technologies, 
> which does not require DetNet and are out-of- scope.
>  

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 14 Mar 2017 20:17:50 +0100

Hi Balázs,

On Tue, 2017-03-14 at 08:49 +0000, Balázs Varga A wrote:
> - FLR values: there are "multiple low layer splits". I would prefer
> to add values only if we can refer explicitly to a standard.

These exemplary numbers refer to the legacy CPRI split (it is option 8
in 3GPP). So we can point to that standard for these numbers, as this
split will continue to exist (regardless of new ones that might
appear).

> - Naming: what is distributed vs. centralized will be network
> scenario and vendor specific. We should speak more about 
> interconnection of functionalities without stating their geographical
> locations. So I am fine to highlight the "co-existence"

OK, agree. Having the focus on interconnection of functions is OK,
instead of reusing the 3GPP terminology of CU and DU.

> - Requirements: here the list is about "data plane transport
> specification". In my view your new bullets are more end2end
> architecture specific requirements (e.g., "supporting multiple
> functional splits simultaneously", "Slicing and 

Here I'm afraid I don't agree. These requirements have direct
implication on the data plane transport, and that is why we bring them
in DETNET.

Thanks,

Carlos

> > > Some fronthaul functional splits considered by 3GPP require the
> > 
> > frame loss ratio (FLR)
> > > to be less than 10E-7 for data traffic and less than 10E-6 for
> > 
> > C&M.
> This is a fair point. The purpose of this was to provide some
> exemplary numbers (which I think are helpful, as provided for other
> use cases in the document). Maybe we can rewrite this part a bit so
> we say "Different fronthaul functional splits are being considered by
> 3GPP, requiring strict frame loss ratio (FLR) guarantees. As one
> example, lower layers splits require FLR to be less than 10E-7 for
> data traffic and less than 10E-6 for C&M", or something like this.
> What do you think?
> 
> >  
> > >    (baseband processing units) and the remote radio heads
> > 
> > (antennae)
> > some items of your list and have found some of them not relevant
> > from
> > DetNet
> > perspective.
> 
> > Subject: Crosshaul input for consideration in draft-ietf-detnet-
> > use-
> > cases
> >  
> > Hi,
> >