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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Balázs,

On Tue, 2017-03-14 at 08:49 +0000, Balázs Varga A wrote:
> 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.

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"
> factor just intend to have better terminology.

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 
> Multi-tenancy-capable", etc.). These are valid requirements but not
> the primary targets of DetNet. 

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

> 
> Cheers
> Bala'zs
> 
> -----Original Message-----
> From: Carlos Jesús Bernardos Cano [mailto:[e-mail]] 
> Sent: Monday, March 13, 2017 5:47 PM
> To: Balázs Varga A <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: Crosshaul input for consideration in draft-ietf-detnet-
> use-cases
> 
> Hi Balázs,
> 
> Apologies for the belated reply. Please see in line below.
> 
> On Fri, 2017-03-10 at 08:18 +0000, Balázs Varga A wrote:
> > Hi Carlos,
> >  
> > Some comments and a question for clarification:
> >  
> > 6.1.4.  Transport Loss Constraints
> > > 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.
> 
> 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?
> 
> >  
> > 6.3.  Cellular Radio Networks Future
> > > 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.
> > 
> > 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.
> >  
> 
> 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"?
> 
> > 6.4.  Cellular Radio Networks Asks
> > > 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.
> 
> Sorry, I don't get what your concerns are here, can you elaborate a
> bit
> more?
> 
> Thanks,
> 
> Carlos
> 
> >  
> > Cheers
> > Bala’zs
> >  
> >  
> > -----Original Message-----
> > From: Carlos Jesús Bernardos Cano [mailto:[e-mail]] 
> > Sent: Friday, March 10, 2017 2:22 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Crosshaul input for consideration in draft-ietf-detnet-
> > use-
> > cases
> >  
> > 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
> >