►
From YouTube: IETF108-RAW-20200730-1100
Description
RAW meeting session at IETF108
2020/07/30 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
All
right,
it's
the
top
of
the
hour.
I
will
say
this
officially
thank
you
to
all
of
you
who
have
joined
us,
no
matter
what
your
time
zone
actually
is.
This
is
the
reliable
and
available
wireless
working
group
and
rick
taylor
and
myself
eve
schuler.
We
are
co-chairs
and
we'll
be
leading
you
through
this
session.
A
A
If,
if
you're
seeing
this
slide,
you
have
successfully
managed
to
join
meet
echo.
Congratulations!
The
nice
news
is
that
the
blue
sheets
are
automatic.
This
time
we
have
a
wonderful
volunteer,
ethan
grossman,
who
will
be
typing
in
minutes
and
as
with
etherpad,
it's
a
shared
set
of
minutes,
so
by
all
means.
Please
you're
welcome
to
also
take
minutes
with
us
with
ethan
and
us
remote
participation.
There
are
people
who
maybe
have
not
registered
or
prefer
to
just
join
the
jabber.
Here's
the
pointer.
A
A
Be
letting
people
know
when
they've
got
a
couple
minutes
left
in
their
presentation
for
the
longer
sessions,
maybe
five
minutes,
but
we've
got
all
five
of
our
drafts
will
be
represented
and
presented,
and
we
additionally
have
a
drill
down
on
the
802.11
update
for
tsn
and
localization.
So
that's
exciting
and
oops.
I
went
in
the
wrong
direction.
A
This
is
what
our
milestones
look
like.
They
have
not
changed,
but
we're
going
to
have
a
discussion
about
them,
so
I
do
want
to
point
out
that
they
there
are
four
boldified
milestones
here.
They
each
represent
a
document
and
we've
got
use
cases
requirements
an
architectural
framework
document
and
ultimately
our
objective
here
is
to
provide
an
evaluation
of
existing
technologies
and
have
a
gap.
Analysis.
B
B
So
we
had
rough
consensus
on
the
working
group
mailing
list
for
the
adoption
of
both
of
those
documents,
but
they
have
not
been
renamed
as
working
group
documents
and
released
because
the
chairs
have
a
couple
of
questions
for
the
working
group
and
rather
than
rename
documents
and
then
potentially
rename
them
again.
We
asked
the
authors
to
just
uprev
the
number
and
and
hold
and
we'll
get
to
those
two
questions
in
a
minute.
B
A
B
Actually,
yes,
that's
that's
very
important
because
some
users
are
on
jabber
and
this
session
is
being
recorded
for
audio.
Can
you
please
state
your
name
at
the
mic
as
though
you
were
an
in-person
meeting
so
that
it's
recorded
so
sorry,
yes,
niels
and
the
ldx
draft
they've
asked
for
working
group
adoption.
We
have
not
officially
asked
for
it
on
the
mailing
list,
but
they're
presenting
their
updates
again
and
they've
presented
a
couple
of
times.
So
I
think
there
may
be
some
interest
in
that
next
slide,
please,
okay!
B
And
it's:
this
is
something
I've
raised
on
the
working
group
mailing
list.
So
if
you
look
at
the
charter
and
particularly
the
milestones
in
the
charter,
they
discuss
documents
that
capture
the
use,
cases
and
the
requirements
and
producing
a
gap
analysis.
So
so
what
I
call
sort
of
horizontal
documents
which
cut
through
each
technology
and
say
no
matter
what
the
technology,
the
the
common
use
cases,
are
x,
y
and
z.
B
Meanwhile,
because
of
we
have
people
working
in
various
parts
of
of
the
wireless
industry
and-
and
you
know
the
usual
people
involved
in
these
things-
and
we
all
know
who
we
are-
we
have
specializations
in
5g
or
ldax
or
802.11,
or
you
know
whatever.
So
it's
we
have
a
number
of
personal
drafts
asking
for
acceptance
by
the
working
group,
which
are
more
technology
vertical
in
manner
in
in
content.
B
So
my
question
to
the
working
group
is:
how
do
we
align
the
charter's
idea
of
how
these
documents
should
look
with
how
they
currently
exist
in
the
personal
drafts
without
discarding
the
really
good
content?
So
this
is
not
a
criticism
of
the
content
in
drafts
because
I
think
they're
really
good
and
I
think,
there's
general
consensus
on
that.
B
It's
not
just
my
opinion
and
without
annoying
the
authors
so
that
they
stop
working
because
we,
you
know
the
working
group
told
them
just
to
change
all
their
documents,
but
still
to
sort
of
align
with
the
milestone
and
charter.
So
this
is
something
really
where
this
is
a
working
group
discussion
and
pascal
is
jumping
to
the
line
yeah.
Let's
I'm
can
I
just
have
a
look.
Is
there
a
second
slide
on
this
one.
B
Yeah,
okay,
so
just
I'm
holding
you
pascal,
I
can
see
you
give
me
a
second.
So
the
the
summary
in
the
proposal
based
on
the
feedback
from
the
working
group
mailing
list
was,
we
can
either
leave
the
charter
as
it
is
changing
the
charter
given.
This
is
the
second
meeting
after
chartering
of
a
working
group
I
have
been
told
by
the
ad
is
an
incredibly
bad
idea,
because
it
makes
us
look
deeply
dysfunctional,
so
changing
charter,
not
necessarily
a
good
idea.
B
D
Okay,
thanks
frank,
so
I
can
just
compare
with
the
working
group
I'm
sharing
right
after
this
one,
so
we
have
lp
one
on
the
second
session
and
healthy
one
is
working
on
an
abstract
compression
mechanism
for
all
sorts
of
networks,
but
still
we
needed
to
have
an
idea
of
the
kind
of
networks
we're
working
on
to
to
be
able
to
to
to
do
the
requirements
right
to
to
the
right
protocol.
So
so
the
first
thing
we
produced
was
this
informational
document
where
we
listed
the
technologies
that
we
considered.
So
we
could.
D
D
D
C
B
Can
we
move
on
to
the
next
slide
eve?
Okay,
so
the
other
question
we
have
for
the
working
group
is
looking
at
the
oam
draft,
which
is
a
really
good
document.
The
decnet
chairs
sort
looked
at
it
as
well
and
said
they
have
an
oam
draft
charter
item
in
detonate
that
nobody
is
authoring
at
the
moment
and
the
oam
draft
put
forward
into
this
working
group
they
considered.
B
Maybe
70
of
it,
was
generic
enough
to
actually
satisfy
their
charter
item
for
an
oam
draft.
So
the
authors
of
the
draft
and
even
myself
and
the
det-net
chairs,
put
a
call
together
earlier
last
well
last
week
to
discuss
this,
and
we
are
all
in
rough
agreement
that
we
can
move
the
large.
The
vast
amount
of
the
current
oam
draft
in
this
working
group
could
actually
be
moved
to
det
net
and
become
a
debt
networking
group
document,
but
the
raw
specific
parts
would
remain
in
the
oam4
raw
draft
in
this
working
group.
B
F
B
In
the
debt
networking
group
on
monday,
there
was
time
I'll
be
quick
on
this
they're
in
the
debt
networking
group.
On
monday,
there
was
consensus
by
the
debt
net
working
group
to
accept
this
proposal,
but
we
do
need
to
confirm
that
the
raw
working
group
is
happy
for
this
as
well,
and
I'm
also
happy
to
take
this
to
the
list.
Pascal
has
a
comment
quickly.
D
Yeah,
I
mean
you
know
I
was
there
creating
that
net
from
the
beginning.
My
belief
is
that
the
debt
net
requirement
is
a
subset
of
the
aurora
requirement.
Currently
enough,
we
have
bigger
and
harder
needs,
and
so
the
way
I
would
like
it
to
be
done
is
more
like
we
progressed
the
document,
so
we
are
sure
that
we
have
everything
that
we
want
covered
and
then,
if
the
two
working
groups
want
to
collapse,
the
two
documents
into
one
and
finish
it
at
that
net.
D
A
G
Hi
this
is
lubricker
as
chair,
so
to
be
clear
on
what
was
decided
discussed
on
monday,
there
was
good
agreement
in
the
room.
We
can't
really
do
consensus
in
a
meeting.
We
have
to
do
consensus
on
the
list,
but
I
think
we're
headed
that
way.
I
believe
the
proposal
was
that
the
generic
portion
of
the
oem
document,
which
there's
a
there,
was
apparently
a
good
amount
of
content.
G
Originally
in
the
latest
version,
I
believe
that's
been
removed,
and
so
the
the
thinking
was
take
that
generic
origin
do
that
in
debt
net,
keep
the
raw
specific
oem
considerations
in
raw
and
work
that
in
parallel
and
if
there's
more
generic
pieces
that
are
identified,
move
them
to
det
net
and
definitely
the
there's
no
intent,
at
least
from
the
discussion.
As
I
understand
it,
to
stop
raw
specific
oem
discussions
in
raw.
You
know
we
think
that's
my
personal
opinion.
I
think
that's
very
important.
A
B
So
I
think
we
should
take
that
one
to
the
mailing
list.
However,
this
very
quickly
jumping
back
to
my
point
about
alignment.
My
question
is
whether
the
authors
of
the
ldax
and
the
5g,
these
technology
vertical
drafts,
whether
we
can
ask
or
whether
the
working
group
should
ask
them
to
contribute
some
of
the
generic,
the
technology,
agnostic,
generic
components
of
those
drafts
to
pascal's,
proposed
technologies,
draft
and
readjust
whether
the
working
group
thinks
it's
it's
it's
worth,
people
doing
that
sorry,
yanosh
is
jumping
in
go
ahead.
Ganache.
H
H
D
Yes,
what
I
want
to
say
is
the
the
technologies
document
as
a
very
fixed
format.
We
are
asking
all
the
participants
and
janus
we'll
talk
about
that.
Just
added
5g
to
prop
up
provide,
provide
us
with
a
very
specific
format
so
that
we
can
actually
derive
a
generic
format
that
would
cover
them
all.
The
intention
is
not
to
describe
in
your
details
what
each
technology
is
exactly
and
still
there
is
interest
in
doing
that,
but
for
that
we
did
not
want
to
impose
a
form.
D
So
basically,
you
can
see
the
specific
technology
documents
like
kenos
or
nils
as
being
free
form,
so
they
can
really
put
whatever
they
want
in
there
and
give
all
the
interesting
information,
whereas
the
technology
is
very
constrained
to
provide
very
specific
information
that
we
ask
so
they're
complementary.
They
are
not
doing
the
same
thing.
Yeah.
A
B
J
J
So
currently
in
the
draft
we
have
like
eight
use
cases.
I
think
I'm
missing
something
in
the
index
in
in
cover,
and
there
is
one
difference
from
the
previous
version
that
was
presented
in
itf
107,
that
is
the
last
one,
on
emergencies
and
in
a
particular
actually
in
a
particular
sub
case
of
emergencies,
which
is
having
instrumented
the
emergency
vehicles
and
there
have
been
a
minor
minor
updates
on
on
the
other
ones.
J
So,
let's
move
to
to
this
use
case.
This
is
an
example.
The
one
is
for
industrial
application.
That
I
think
is
a
very
relevant
example
for
for
raw
technologies.
So
we
have
an
industrial
factory
or
plant
where
we
have
different
devices,
actuators
and
sensors.
That
may
be
wirelessly
connected
or
also
wired,
while
connected
by
wired.
So
we
we
may
have
dead
net
kind
of
networks.
In
addition
to
wireless
multi-hop,
heterogeneous
networks,
we
have
control
loops
and
we
have
monitoring
traffic.
J
J
Then
we
have
a
more
detailed
section
on
a
specifics
of
the
use
case,
considering
the
the
wireless
approach
and
the
on
the
actual
specifics
of
the
of
the
particular
use
case.
For
example.
In
this
case,
the
fact
that
we
may
have
a
telegenius
wireless
technologies
and
wire
technologies
is
a
key
specifics
that
we
may
have
multiple
simultaneous
links
transporting
or
sending
or
traffic
for
the
same
flow.
J
It's
also
relevant
characteristics
that
we
may
have
variable
link
conditions,
even
if
we
don't
have
a
lot
of
mobility
in
this
scenario,
because
things
are
moving,
I
mean
we
have
mobile
parts
in
robots
that
are
moving
and
that
may
change
the
characteristics
of
the
links
and
that
we
have
different
traffics
with
different
needs,
control
loops.
We
have
reliability
key
there
and
low
latency
is
required,
but
then
we
may
also
have
monitoring
and
diagnostics
traffic
that
don't
require
that
amount
of
reliability
and
availability,
and
that
shouldn't
be
mixed
with
the
other
kind
of
traffic.
J
If
we
kind
of
merge
these
two
milestones
of
the
group,
the
use
cases
and
the
requirements
that
will
be
a
key
part
of
the
draft
as
well
in
this
case
for
the
wireless
for
industrial
applications,
the
two
key
requirements
are
that
the
on
the
one
hand,
the
solutions
must
be
backwards
compatible.
So
we
need
to
be
able
to
support
both
regular
kind
of
multiplex
flows
and
flows
requiring
predictable
behavior
and
that
the
solutions
should
also
work
covering
or
over
multiple
technologies,
wireless
and
wired
technologies.
J
Then
here
I
will
have
another
use
case,
but
I
will
skip.
Basically,
this
is
the
gaming
one
and
there
we
have
more
specific
kind
of
requirements,
for
example
for
latency,
but
what
this
is
just
an
example,
and
then
if
I
go
to
the
next
to
the
last
slide
just
to
to
conclude
so
in
the
current
draft,
we
have
eight
eight
use
cases
already
covered
there.
There
were
others
mentioned
in
previous
meetings
like
smart
grid.
J
J
So
question
to
the
chairs
will
be
when
whether
we
should
do
it
and
when,
if
so,
submit
us
data
ftf
and
then
question
for
the
rest
of
the
working
group,
whether
we
should
document
additional
use
cases-
and
maybe
we
should
start
working
already
with
the
with
the
authors
or
editors
of
the
potential
draft
idea
for
architecture
for
working
on
the
on
the
sp
on
the
requirements.
So
better
characterize
the
requirements,
and
that
will
be
all
from
my
side.
I
try
to
keep
it
short.
B
F
B
K
E
K
Okay,
so
thanks
again
everyone
for
the
opportunity
to
to
present
here
today.
My
name
is
dave
cavalcanti
and
I'm
co-author
in
this
presentation
with
ganesh
rebecatism,
both
from
intel
so
we'll
provide
an
update
on
wi-fi
and,
more
specifically,
on
the
tsn,
related
capabilities
and
focus
on
low
latency
and
determinism
right.
So
we
presented
a
couple
of
meetings
ago
and
we'll
focus
more
on
the
new
developments
and
the
wi-fi
seven
capabilities
and
localization
as
well,
so
there's
a
short
offline.
K
You
know
in
this
interest
group
report
that
is
available,
and
you
know
there
is
a
presentation
in
the
report
with
detailed
requirements
and,
as
you
can
see
in
the
list,
I
won't
go
through
all
the
numbers,
but
the
robotics
industrial
automation
and
gaming
were
the
main
driving
use
cases.
You
know
it
seems
to
be
very
aligned
with
the
use
cases
in
in
raw
one.
K
Take
away
from
from
this
report
and
use
cases
is
that
the
the
main
challenge
of
gap
at
this
point
is
really
enabling
guaranteeing
worst
case
latency
in
jitter
right.
You
know,
in
other
words,
more
determinism
in
wi-fi,
so
so,
and
that
is
driving
many
of
the
new
developments
in
the
the
next
generation
wi-fi
standards
that
we'll
talk
about,
but
already
in
wi-fi
for
quite
some
time.
K
K
So
forth,
as
we
know,
time,
synchronization
is
a
core
feature
right
to
do
scheduling
and
of
data
at
the
right
time,
right
with
the
feminism
and-
and
this
has
been
already
enabled
in
dot
11
for
a
few
years.
The
2016
specification
adds
two
protocols,
a
tiny
measurement
and
fine
time
in
measurement
protocols
for
time
synchronization.
K
But
the
point
is
like
both
of
those
can
enable
time,
synchronization
and
and
operate
with
the
tsn.1as
time
synchronization
protocol
and,
in
addition
to
time,
synchronization.
You
actually
get
geolocation
and
positioning
as
an
added
value
and
we'll
talk
more
about
that
at
the
end,
which
may
be
a
another
benefit
from
any
applications,
and
so,
in
addition
to
time,
synchronization.
K
Another
important
feature
in
tsn
for
many
of
the
industrial
applications
is
the
capability
to
do
time,
hour,
scheduling
or
time
or
shaping,
and
the
basic
idea
can
also
be
applied
in
wi-fi
where
you
can
control
the
different
keys
in
a
wi-fi
station
and
network
in
in
a
time
aware
basis,
so
that
the
right
key
or
the
right
station
is
allowed
to
transmit
at
certain
times
where
the
other
keys
are
are
closed.
And
you
know,
of
course
this.
K
And
this
this
feature,
when
combined
within
the
recent
update
in
in
the
wi-fi,
6
or
11ax
specification,
which
adds
to
the
trigger
bases
schedule
operation,
has
it's
very
powerful
tool
to
achieve
the
the
latency
and
reliability
guarantees.
You
know
that
are
expected
in
many
of
those
applications
that
we
discussed.
K
So
this
operation
allows
you
to
transmit
multiple
frames
simultaneously
and-
and
there
are
multiple
configurations
and
allocations
in
terms
of
amount
of
resource
and
mcs,
that
every
station
gets
and
with
this
capability
it's
supposed,
the
ap
can
basically
schedule
and
try
to
meet
the
deadlines
right
with
reliability
constraints
as
well.
So
what
the
figure
on
the
right
shows
is
a
simulation
where
we
look
at
the
number
of
stations
in
in
a
certain
area
and
try
to
to
find
given
a
a
latency
bound
right.
K
If
I
have
a
deadline,
how
many
stations-
and
that's
the
capacity
here-
how
many
stas
can
be
supported
for
a
given
latency
bound
with
99.99
reliability
and
in
this
reliability
means
here
the
fraction
of
packets
that
successfully
delivered
within
that
latency
bomb.
So,
as
you
can
see
in
the
figure
for
a
given
latency
bound
with
the
11x
trigger
base
access,
you
can
support
a
certain
number
of
of
simultaneous
stations
right
with
100
bytes
packets,
in
this
case,
so
from
nine.
K
If
you
have
one
millisecond
bound
to
you
know
45,
if
you
have
three
milliseconds,
so
there
is
a
trade-off,
of
course,
between
latency
and
the
capacity
here.
But
just
is
important
to
understand.
In
these
simulations
we
use
20,
megahertz
channel
and
and
in
wi-fi
you
can
operate
in
20
megahertz
40
megahertz,
80,
megahertz
160..
K
K
So
another
important
new
development
is
the
the
wi-fi
6e,
which
means
11ax
operation
extended
in
the
new
6
gigahertz
band
that
has
been
opened
up
in
the
us
and
is
in
the
process
of
being
open
in
many
countries.
Products
with
these
capabilities
are
expected
to
large
in
in
wi-fi
alliance.
Specification
certification
is
expected
to
launch
in
january
and
next
year.
K
You
have
more
flexibility
to
really
adapt
the
network
to
interference
and
congestion
and
become
more
resilient
right
to
any
unmanaged
threats
that
that
may
occur
right
because
it's
still
unlicensed
operation
right.
So
other
systems
can
show
up
in
the
band,
but
you
know
with
this
availability
of
spectrum:
you
can
monitor
the
network,
you
can
adapt
and
you
can
apply
redundancy
which
are
important
features
that
you
know
raw
is
probably
going
to
develop
as
well
so
now
shifting
to
what
is
coming
next
right
and
and
it's
gonna
be
called
wi-fi
seven.
K
We
can
also
get
a
higher
reliability
because
we
can
duplicate
packets
over
multiple
channels
or
multiple
links,
and
we
can
also
do
traffic
steering
and
separation
where
certain
traffic
can
be
steered
to
certain
links
and-
and
that
is
also
a
mechanism
that
can
avoid
congestion
right.
So
these
are
new
tools
that
can,
you
know,
be
used
to
to
provide
these.
You
know
low,
latency
and
or
reliability
right,
of
course,
with
the
higher
throughput
gains.
K
K
The
key
point
here
is
that
we
are
extending
this
coordination
and
you,
you
saw
the
scheduling
capability
right,
that
11ax
is
enabled,
so
so
this
coordination
will
extend
that
beyond
a
single
basic
service
set
of
bss
right
or
a
single
wi-fi
cell,
to
provide
more
control
over,
for
example,
latest
or
reliable,
together
with
multiple
aps
in
in
in
a
certain
area
right.
So
this
will
address
some
of
the
previous
limitations
with
the
overlapping
aps.
K
Almost
done,
thank
you
and
the
final
enhancement
is
in
the
area
of
latency
right.
So
you
know,
we
know
that
the
11ax
can
achieve
a
single
digital
effect
manufacturing
latency
already,
but
the
worst
case,
lady,
can
still
vary
with
congestion,
and-
and
we
know
that
with
the
higher
bandwidth
in
wi-fi
seven,
we
we
can
multi-links,
we
can
get
even
lower
latest,
but
there
is
still
need
to
enhance
the
operation
towards
more
deterministic
behavior
and
there
are
a
number
of
features
that
are
being
introduced
with
new
key
os
provisioning
models.
K
So,
finally,
just
to
add
that
you
know
we
also
have
in
wi-fi
localization
right
with
ftm
you
can
achieve
in
line
of
sight
around.
You
know
a
bit
less
than
a
meter
in
accuracy,
so
stations
can
do
positioning
with
that,
and
you
know
applications
that
cannot
access.
Gps
could
leverage
these
mechanisms
as
well,
which
is
the
same
that
can
be
used
for
time
synchronization,
and
then
there
is
enhancement
on
going
in
11
ac,
which
extends
some
of
the
the
ranging
capabilities.
K
As
far
as
you
know,
a
summary
you
know
we
have
seen
a
lot
of
these
capabilities
already
exist.
You
know
I
find
that
more
are
being
introduced.
We
have
captured
some
of
them
in
the
in
the
technologies
draft,
but
perhaps
some
of
the
latest
development
and
wi-fi
seven
features
can
be
updated
because
there
has
been
more
more
development
and-
and
we
know
more
now,
what
it
will
be
coming
up
in
wi-fi,
seven
and-
and
you
know,
I
think
that
can
can
help
drive
the
requirements
and
the
solutions
in
this
group
as
well.
A
K
K
So
one
of
the
new
updates
in
wi-fi
seven
is
that
we
are
trying
to
introduce
again
a
mechanism
for
stations
to
negotiate
qos.
Basically,
the
station
provided
requirements
and
the
network
do
admission
control
based
on
that,
and
we
are
proposing
a
type
of
new
service
around
low
latency
with
high
reliability
that
can
be
negotiated
and-
and
there
will
be
new
signaling
to
to
to
establish
that,
and
then
some
of
the
other
capabilities
listed
here
are
going
to
be
used
to
provision
right.
K
L
Hello,
do
you
hear
me?
Yes,
okay,
I
have
a
comment
about
latency,
because
I
was
surprised
when
I
hear
hear
that
latency
would
be
10
times
worse
compared
to
3gbp
to
5g,
for
example,
in
5g
latency
for
wireless
link
is
half
a
millisecond
by
standard,
and
some
vendors
has
shown
even
one-third
of
milliseconds
in
real
test.
Why?
It's
important?
L
Because
if
you
have
human
and
you
would
like
to
be
human,
real-time,
you
really
should
have
one-way
latency
five
millisecond
for
all
for
everything
for
all
transmission.
If
you
have
time,
I
could
explain
your
wi-fi
because
it's
easy
to
calculate.
It's
originated
from
25
millisecond
resolution,
which
human
has
as
a
human,
but
okay,
five
milliseconds
latency
one
way
in
3gbp,
because
you
have
only
half
a
millisecond
by
standard.
L
You
still
have
a
budget
to
have
a
long
distance
to
have
some
long,
fiber
long
fiber
I
mean,
if
you
a
few
hundred
kilometers
it'd
still
be
your
application
could
be
still
in
neighboring
cities.
It's
not
it's
not
mandatory
to
have
application
in
the
same
metro.
It
could
be
in
different
city,
but
in
wi-fi
seven,
as
I
understand
you
still
plan
something
like
five
milliseconds,
it's
a
whole
budget
which
you
have
for
human
real
time.
You
don't
have
any
even
more.
L
It
means
that
your
application
should
be
always
in
the
same
matter,
small
distance,
small.
I
mean
something
like
up
to
50
kilometers
24,
because
because
speed
of
light
and
fiber
is
five
microsecond
per
kilometer.
For
that
reason,
you
are
restricted
to
some
metro.
If
it's
exactly
what
you
want,
if
you
would
like
to
have
only
so-called
local
communication,
it's
not
wide
area
network
and
you
will
always
would
be
behind
wireless
for
3gbp.
Then,
okay,
it's
fine!
It's
your
choice!
It's
it's
a
use
case!
K
K
Question
exactly,
but
you
know
just
to
clarify
the
the
latest
in
wi-fi
it,
it
can
be
a
few
microseconds.
Actually
you
know
that
is
because
there
is
no
fixed
frame
structure
so,
depending
on
your
data
size
and
bandwidth,
it
can
be.
You
know,
200
microseconds
right,
so
there
is
no
limitation.
In
that
sense,
I
think
the
number
you
called
here
five
is
more
user
requirements
that
you
know
if
we
are
targeting
applications
that
from
end
to
end
are
those
you
know
are
trying
to
get
those
requirements
right.
Five
milliseconds,
for
example,.
B
B
K
A
C
M
E
M
So
yes
welcome
everyone
thanks
for
joining
us,
so
today
I'm
going
to
present
an
updated
version
of
our
aldex
idf
draft.
In
the
version
of
four
at
itf
107,
we
presented
version
one
and
since
then
some
several
things
have
changed.
So
next
slide.
Please
we've
written
well,
but
I
think
we
went
over
that
already.
So
that
is
the
abstract
for
for
a
draft
and
there's
one
important
line
that
we
added
since
then,
and
the
last
one
high
reliability
and
availability
for
ip
connectivity
over
aldex
are
essential.
M
M
That
means
an
air
traffic
controller
controls,
a
very
small
sector
in
the
sky,
where
aircraft
pass
by
and
then
they
go
to
the
next
sector
and
the
next
sector,
and
in
2004
there
was
the
first
attempt
to
unify
that
into
a
one
sky
so
into
a
sectorless
sky,
and
for
that
new
data
links
were
needed
and
since
then
those
data
links
are
being
developed
and
as
of
now,
there
are
several
digital
data
links
for
safety
of
life,
communications
for
aeronautical
communications,
one
of
them
is,
for
instance,
video
mode
2.
That's
a
data
link.
M
That
is
most
known
to
to
all
of
us.
I
guess,
but
it's
it's
not
usually
standardized
in
most
aeronautical
protocols,
and
that
would
be,
for
instance,
key
and
trust
management.
There's
another
system
for
airport
communication
called
aeromax
that
also
has
a
pki
already
incorporated
into
it.
Ldx
would
probably
go
with
the
same
procedure.
M
We
have
mutual
authenticated
key
exchange
protocols,
key
deliveration
measures
so
because
one
of
the
three
gpp
guys
was
here
so
basically
following
the
same
approach,
so
we
do
an
attachment
procedure
and
then
afterward.
We
secure
the
link
to
the
management
entity
within
the
ground
network
and
then
the
communication
between
aircraft
and
ground
station
is
especially
the
signaling
or
control
plane
is
secured.
M
Afterwards.
We
have
secure
logging
and
availability
robustness
measures
that
I
will
talk
about
in
a
moment
and
comparatively
high
data
rates.
I
know
those
don't
seem
high
if
you
compare
it
to
5g
or
something,
but
please
keep
in
mind.
There
are
studies
that
an
aircraft
at
the
moment
is
perfectly
fine
with
about
one
kilobit
of
data
per
aircraft
and
ldx
assumes
to
have
mostly
up
to
500
aircraft
in
one
cell,
so
1.55
or
1.4.
M
Megabits
would
suffice
for
that,
and
also
please
keep
in
mind
that
ldex
only
has
500
kilohertz
of
bandwidth,
so
it
has
way
less
bandwidth
and
spectrum
than
for
instance,
5g
has
then
here
we
see
the
applicability
and
why,
where
ldx
comes
into
play,
so
we
have
satcom
communication
for
oceanic
poll
and
remote
domains
for
airport
communication.
I
already
mentioned
that
that's
aeromax,
that's
already
in
use
and
then
there's
the
ldx
air
ground
link
that
I'm
talking
about
right
now.
M
So
this
air
ground
link
enables
new
services,
for
instance,
like
4d
trajectories,
so
virtual
points
in
the
air
where
aircraft
can
fly
by
and
a
broader
controller
pilot
data
link
communication.
So
it's
cp,
dlc,
link,
business
communications
and
also
ldx
can
be
used
as
a
pnt
navigation
as
alternative
to,
for
instance,
gps
and
last
but
not
least,
and
there's
also
an
add
to
air
extension.
So
aircraft
can
talk
directly
to
other
aircraft.
M
So
that's
everything
that
we
added
in
version
of
three.
Now
in
version04,
we
added
the
robustness
measures,
and
this
is
the
protocol
stack
of
aldex
of
the
physical
layer,
mac
layer,
data
link
services,
dls
lms,
the
aldex
management
entity
and
snp
has
a
subnetwork
protocol
and
at
the
mac
layer
we
have
a
static
frame
structure
that
I'm
going
to
talk
about
in
a
minute,
then
the
edx
management
entity
has
a
robust
resource
scheduling
and
that's
entirely
a
ground
station
controlled
and
also,
for
instance,
as
the
event
that
the
ground
station
sees
too
many
aircraft.
M
At
the
data
link
service,
we
have
a
selective
and
repeat
irq
protocol
and
showing
timely
delivery,
especially
by
of
messages
with
a
higher
priority
and
the
physical
layer
in
the
forward
link.
So
that's
from
the
ground
to
aircraft
way.
We
have
a
continuous
ovm
stream
and
on
the
reverse
link
we
have
radio
bursts
of
ofdm
rtdma
bursts
with
robust
and
adaptive
coding
and
modulation,
and
now
for
the
aesthetic
frame
structure.
M
Here
we
see
that
in
the
forward
link
we
have
a
broadcast
channel
where
a
ground
station
announced
their
existence
to
the
world.
We
have
several
multi
frames,
that's
mf
and
in
the
multi-frames
we
have
a
data
channel,
that's
the
dch
and
the
ccch
is
where
resources
can
be
given
to
an
aircraft
and
in
the
reverse
link.
We
see
that
there's
a
random
access
channel
with
four
multi
frames
and
aircraft
can
request
resources
in
the
dcc8
as
the
dedicated
common
control
channel
and
then
the
data
channel
afterwards.
M
Minutes
left
perfect,
thank
you
and
then
there's
a
an
update
already
waiting
for
version
05,
because
thank
you
very
much
for
the
feedback.
So
far,
we've
received
some
and
we're
we're
currently
in
the
process
of
incorporating
that
into
version
405,
and
we're
also
working
on
pointing
out
more
clearly
why
ldx
is
required.
What
problems
it
solves
then
also
the
interoperability
and
modularity
of
the
aldix
radio
is
one
point.
M
Then
we
had
a
very
good
comment
about
the
amount
of
terrestrial
access
points,
because
ldx
cells
can
can
have
a
huge
range
up
to
200
nautical
miles,
and
the
question
is:
is
that
a
little
bit
too
much?
So
if
you
reduce
that,
do
we
have
more
capacity
in
the
cells
themselves,
then
security
relations
that
need
to
be
clarified
and
also
the
application
of
quality
of
service
communication
to
ldex.
So
those
are
in
the
pipeline
already
and
we
welcome
any
more
feedback.
M
B
M
B
D
B
D
D
So
we
we
elected
a
set
of
radios,
and
basically,
we
asked
specialist
of
each
of
those
radios
to
ask
a
sec
to
to
write
a
section
in
this
draft,
so
we
can
actually
provide
this
information,
so
I
just
placed
an
extract
from
the
table
of
contents
on
the
right,
and
that
extract
is
from
the
the
new
addition.
Thanks
to
janus,
we
have
now
5g,
which
was
the
missing
piece
in
this
document.
D
Actually,
janusz,
we
will
discuss
a
little
bit
about
how
you
arrange
things,
because
this
section
6.3
should
really
be
folded
into
the
other,
but
the
main
three
sections
that
we
have
been
asked
asking
for
or
from
all
the
participants
were
provenance
and
documents.
So
with
this
we
know
where
to
get
the
specification,
we
can
also
derive
whether
the
specifications
are
readily
available,
whether
there
is
ipr
and
whether
they
are
from
open
standards
etc.
So
we
can
check
they
have
all
the
good
properties
in
terms
of
performance.
D
Then
there
are
characteristics
so
we
can
derive
whether
they
can
be
scheduled.
Obviously
they
can,
because
that's
how
we
pick
them
or
you
know
what
kind
of
of
latency
we
can
expect
and
what
kind
of
traffic
we
can
push
with
what
kind
of
api
and
then
more
specifically,
we
asked
every
author
or
section
author
to
provide
us
with
how
and
why
this
can.
This
technology
can
be
used
for
deterministic
flows
and
that's
where
it
becomes
very
specific
to
to
the
raw
work
and
what
generic
abstraction
we
can
derive
for
that
particular
radio.
D
And
then
we
would
merge
that
with
the
other
abstraction
and
build
this
generic
abstraction
of
all
of
them.
So
thank
you
again,
yanash
for
this
news
text.
With
this
I
believe
the
spec
is
complete.
We
have
ordered
the
the
major
content
piece
that
we
wanted
like
I
said
there
should
be
for
this
new
section,
a
little
bit
of
discussion
between
english
and
me
myself,
maybe
for
just
a
bit
of
reorg,
but
the
content.
D
B
So,
thank
you
pascal
rick
here.
Yes,
I
will
ask
for
working
group
adoption
on
the
mailing
list
and
from
a
personal
opinion.
I
think
this
goes
a
long
way
to
addressing
my
concerns
about
having
lots
of
documents
about
specific
technologies
without
addressing
the
commonalities
for
raw.
So
I
would
be
very
happy
to
suggest
that
the
working
group
updates
its
milestones
to
include
this
document,
because
I
I
think
this
is
a
really
valuable
piece
of
work,
and
that
applies
to
the
whole
author
team,
not
just
you
so
thank
you.
B
D
B
D
Okay,
that's
good,
so
I
have
more
slides
on
this
one
that
so
I'll
be
using
the
time.
Just
let
me
know
when
we're
getting
short,
so
there
was
a
lot
of
work
on
this
document
since
last
time
we
got
early
reviews
when
the
document
was
mostly
the
prime
statement.
So
if
you
remember
around
itf
106,
I
don't
complace
it
with
106.7,
but
somewhere
between
there.
I
was
working
on
the
prime
statement
and
then
the
charter
came
in
and
said:
no,
we
don't
want
a
prime
statement.
D
We
want
a
framework
and
architecture
blah
so
compared
to
that
that
was
actually
faster
than
I
thought
it
would
be
right.
I
thought
we
would
do
prime
statement
requirement
understand
where
we're
going
and
then
and
then
write
this
this
framework
or
this
architecture,
but
but
the
the
the
charter
was
already
talking
about
architecture
and
framework.
D
So
I
I
put
the
table
of
contents
on
the
right
and
so
there's
still
a
lot
of
of
the
original
prime
statement
work
so
section
three
section
four
so
so
part
of
that
is
actually
the
requirements.
So
now
we
have
a
chartered
item
for
requirements,
so
you
may
tell
me
hey
you
need
to
split
this
document,
but
just
that's
how
life
came
in
you
know
these
things
evolve
right
now.
Everything
is
in
this
one
document,
so
you
can
find
prime
statement
stuff.
D
D
So
for
the
prime
statement
piece,
there
are
two
items
that
are
discussed
in
the
charter.
One
is
how
do
we
interact
and
what's
the
relation
with
other
working
groups
and
the
other
one
is
requirements
and
I'll
go
I'll,
go
more
in
more
slides
over
those
things,
then,
for
the
framework
piece
right
now
we
have
basically
terminology.
So
we
we
need
to
define
what
we
call
reliability
and
availability
in
the
first
place,
and
so
we
had
this
great
command
by
anarch
hey.
D
We
should
not
be
redefining
those
terms
we
should
inherit
them
from
somewhere
and
actually
terminology
that
we
use
in
this
document
is
is
very
little.
Adapt
adaptation
from
the
concept
in
nasa
that
they
use
for
the
space
shuttle,
and
then
we
we
look
at
the
gaps
and
which
is
also
a
choice
of
discussed
in
the
charter.
But
what
kind
of
gaps
does
row
want
to
address
versus?
What
is
being
done
in
the
other
working
groups
and
and
what
exists
already
in
ap?
So
that's
what
I
call
right
now,
the
framework.
D
It's
not
really
a
framework.
We
should
have
a
big
picture
of
the
whole
thing.
This
big
picture
is
not
there
yet,
but
it
would
fit
in
this
kind
of
framework
subset
of
this
document,
and
then
I
started
writing
a
lot
of
new
text
about
the
architecture,
because
that's
really
what
people
asked
on
the
mailing
list.
So
there
are
two
sections
right
now
in
architecture.
D
So
that's
that's.
This
wireless
element,
things
the
tracks
and
the
power
function,
and
then
I
started
this.
This
architecture
thing,
which
is
section
seven,
where
we
discussed
this
psc-
that
we
introduced
at
iatf
106,
where
which
is
this
new
element
that
is
actually
in
the
device
stack
and
that
makes
the
the
path
selection
for
this
packet,
then
I
also
discussed
the
raw
oam
design
and
needs,
but
it's
very
high
level
right.
It's
not
competition
with
the
om
spec,
just
placing
it
as
an
architecture
object.
Then
I
talk
about
path,
notification
and
flight
notification.
D
D
So
now
I'm
going
slide
by
slides
over
those
two
things
that
are
in
the
spec,
so
so
this
row,
interaction
with
other
working
groups,
was
already
there
in
the
prime
statement.
It
was
already
there
when
we
discussed
the
working
group
at
a
106,
so
I
won't
extend
spend
time
on
it,
but
please
come
back
on
the
meeting.
Let's
start
with
questions
on
this,
so
basically
we're
saying
hey
row
is
a.
We
are
an
overgrown
subset
of
that
net.
D
We
are
looking
at
those
links
which
are
which
have
different
properties,
so
we
need
to
do
extra
stuff
for
them,
those
extra
stuff
being
optimizing,
the
the
the
spectrum
and
the
energy
and,
at
the
same
time,
pro
pro
providing
end-to-end
reliability.
When
a
particular
link
may
not
be
reliable
at
one
point
of
time,
then
we
we
go
through
the
requirements
and
compare
to
the
to
the
buff.
D
Now
a
common
use
case,
like
my
iphone,
is
I've
got
4g
access.
I've
got
wi-fi.
I
need
to
get
this
packet
to
the
internet.
Should
I
use
5g?
Should
I
have
4g?
Should
I
use
wi-fi?
Should
I
use
both
and
do
replication
elimination
and
that
kind
of
decision
cannot
be
done
within
the
the
one
radio
adapter,
because
it's
across
those
technologies?
D
So,
as
you
start
thinking
like
this
row
kind
of
moves
a
little
bit
away
from
that
net,
because
that
network
considers
every
hop
I
mean
if
you,
if
you
break,
if
you
don't
have
end
to
end.net
and
20
cents,
all
bets
are
off
because
you're
looking
at
very
hard
bond
with
something
like
the
access.
Well,
if
you
can't
guarantee
the
rest
of
the
network,
then
you
cannot
guarantee
a
hard
bond.
You
just
want
to
optimize
the
quality
of
your
access.
D
If
you're
just
doing
that
without
the
outbound,
then
you
don't
need
to
schedule
every
hub.
You
don't
need.
You
can
just
say
hey.
This
access
seems
to
work
better
than
this
other,
and
so
so
this
this
access
selection
kind
of
operation
is
new
to
this
draft
and
was
not
there
at
the
time
of
the
path
it
just
came
out
of
the
discussions
we
had
so
now
we
have
those
two
major
use
cases:
the
access
and
the
mesh.
Basically.
D
So
just
some
texture
about
the
reliability
and
you
have
this
link
on
the
nasa
side.
Basically,
what
I'm
saying
is
those
words
don't
come
from
us
this.
This
wording
is
just
a
very
slight
adaptation
of
of
the
industrial
technology.
I
mean
the
ot
wording,
but
just
applied
to
networking,
so
you'll
find.
If
you
read
the
draft
that
we
use
the
generic
definition
and
say
we,
then
we
say
hey
when
we
apply
this
to
networking
here
is
what
it
means.
D
Then
a
little
bit
of
gap,
analysis
and
that's
when
we
have
this
discussion
that
we
had
at
the
buff
about
the
the
basically
the
pc,
seeing
a
large
network
and
seeing
all
those
links
and
making
you
know
long
time
decision,
whereas
when
the
links
quickly
flaps,
because
there
is
something,
for
instance,
you
know
in
the
middle,
you
can't
redefine
your
whole
path.
You
you
need
to
to
do
reliability,
viability,
local
decision
with
this
psc
that
we
introduced.
D
So
now
we
have
this
this
comparison
between
what
we
do
in
raw
and
what
we
do
in
that
net
and,
like
I
said
we
can
see
it
as
an
overgrown
small
small
piece
of
that
net.
We
can
also
see
that
if
we
start
introducing
that
there
are
non-row
nodes,
so
I
made
the
generate
picture
here
where
you
actually
traverse
a
cloud
in
one
of
the
legs
of
this
particular
track
and
that
cloud
is
not
controlled
by
a
row.
So
if
you
see
this
picture,
you
figure
that
hey.
D
I
can
do
some
oam
on
on
each
hub,
if
you
like,
some
via
local
bfd
or
using
mana
dlip,
for
instance,
on
each
of
those
links
to
observe
them,
but
I
cannot
observe
the
cloud
in
yellow
here,
so
I
can
have
a
layer,
3
oam,
which
will
tell
me
from
the
egress
to
the
ingress
what
kind
of
reliability
variability
I
observe.
I
can
also
observe
some
of
those
links
where
you
have
row
nodes.
D
But
if
you
go
through
a
cloud,
then
you
probably
lose
your
heart
bound,
but
you
you,
you
cannot
observe
every
hop
at
the
same
time
so
row.
We
need
to
agree
on
that,
but
rome
may
kind
of
differ
from
that
net.
In
that
we
we
may
need
to
traverse
this
yellow
clouds
and
lose
the
outbound
latency.
At
the
same
time,
then
we
discussed
iom
and
oom.
D
So
the
ingress
can
make
a
decision,
so
there
is
in
band
or
am
with
the
packet
going
left
to
right,
or
they
could
be
out
of.
Bandwidth
am
left
to
right
or
right
to
a
left.
If
there
is
a
yellow
piece
like
the
in
the
multi-access
case
that
would
be
the
internet,
then
we
cannot
observe
hub
by
hop
what
goes
in
the
yellow
piece.
We
can
observe
the
layer,
2
hops
between
row
nodes
and
we
can
observe
the
end-to-end
layer
3.
D
D
This
other
thing
is
also
in
the
draft
and
it's
it's
not
it's
not
a
stack,
but
it's
the
closest
thing
we
have
to
to
to
a
stack.
We
basically
show
three
methods
of
learning.
One
of
them
is
iom,
and
also
I
control
by
a
control.
I
mean
a
if
if
the
ingress
decides
which
subset
of
the
track
is
going
to
be
used
left
to
right
then,
but
the
actual
forwarding
like
replication
can
happen
in
the
middle
of
the
network.
D
D
So
we
from
an
individual
node
in
the
middle,
we'll
learn
from
this
om
and
control
about
this
particular
packet.
It
will
make
a
forwarding
decision.
Should
I
replicate,
should
I
just
forward
it
to
a
or
b
and
then
it
it
may
re-tag
the
packet
based
on
to
provide
additional
learning
for
the
next
steps,
for
instance
about
the
quality
that
that
was
observed
so
far,
the
path?
D
What's
observed
about
this
particular
layer,
2
link
and
then
on
the
right,
we've
got
the
out
of
band
oam,
which
are
packets,
which
circulate
between
the
row,
notes
and
and
give
us
some
out
of
the
information
about
the
the
network.
Based
on
all
this
learning,
you
see
this
red
beast
in
the
middle,
which
maintains
the
forwarding
state,
which
basically
says
oh
for
this
particular
flow.
There
is
what
I'm
going
to
do
right
and
that
that
fits
together
with
the
the
inbound
control
that
fits
into
the
forwarding
decision.
N
D
That's
one
way
of
doing
it,
so
that
will
basically
learn
what
what
you
said.
You
know
the
link
states
across
the
the
path,
but
using
vfd
or
remote
bfd
is
the
way
to
do.
This
is
one
way
one
classical
way
of
doing
this.
End-To-End
3
knowledge
that
I
also
illustrated
here
when
we
oh
here
actually
when
we
wanted
to
see
not
just
the
raw
note
to
run
node
layer,
2
interaction,
but
the
ingress
node
to
egress
node
result
like
the
quality
of
the
transmission
between
ingress
and
at
layer.
3..
D
When
I
say
row
observes
the
layer
3
end
to
end
operation.
The
last
sentence
in
this
slide-
that's
I
mean
remote
bfd
is
an
example
of
that,
and
how
do
we
do
that?
Could,
since
we
are
not
doing
a
serial
pass,
we
are
doing
this
graph
is
left
to
be
defined.
Do
you
want
to
observe
just
one
path
over
the
one
serial
path
that
is
within
this
track,
although
we
want
to
observe
the
whole
track,
so
bfd
is
very
much
in
there.
Yes,.
N
Yes,
but
again,
if,
if
active,
oem
is
not
in
band
with
the
traffic,
in
my
opinion,
it's
really
useless
because
it
doesn't
help
you
to
understand
their
exp.
The
experience
of
the
treatment
that
their
data
flow
receives
so
being
in
bed
with
a
data
flow
is
a
essential
requirement
for
any
active
oem
mechanism.
D
D
Let
me
go
back
to
it,
which
is
actually
another
differentiator
with
what
that
does
at
this
very
moment,
which
is
the
encapsulation
and
the
encapsulation
game,
you
see
section
7.4,
we
actually
kind
of
mandate
that
what
decides
the
packet
treatment
is
not
the
flow
right
now,
and
I
I
remember
discussion
with-
we
need
to
have
that
on
the
main
list,
maybe
but
the
basically
what
what
decides
the
forwarding,
what
the
psc
uses
as
hey
here
is
this
thing
that
I'm
going
to
place
in
this
path?
That
is
not
the
flow.
N
B
B
G
Excellent
slide:
seven,
please,
seven
back
to
a
comment
that
was
made.
I
think
going
even
at
the
the
boss
is
my
understanding,
and
I
believe
this
was
the
understanding
and
time
of
chartering
or
the
consensus
of
time
of
charting.
You
know
as
an
observer
or
an
individual,
the
that
raw
provides
the
adaptation
from
general.net
network
collection
of
general.net
networks
to
the
wireless
network.
G
So
it's
almost
like
the
the
it
provides
adaptation
to
the
subnet
technology
or
collection
of
something
that
are
wireless.
This
picture
implies
to
me
that
the
world
is
raw,
so
it'd
be
really
nice
to
see
from
an
architectural
standpoint
how
raw
fits
in
with
the
rest
of
that
net
and
from
both
slide
seven
and
slide
eight.
I
find
that
it's
really
hard
to
tell
you
know.
G
B
G
B
D
If
there
is
something
I
missed
about
the
comments,
the
comments
that
were
made
during
the
buff
were
not
fully
well
captured
and
I
tried
to
address
them,
but
but
I
missed
something,
that's
and
I
I
really
did
not
really
understand
the
mic
either,
but
I
tried
to
to
to
answer
everything
on
the
mailing
list.
If
I
missed
anything,
I
I
must
apologize
and
yes,
please
I'm
sorry
for
once.
I
will
ask
you
to
repeat,
but
I
mean.
A
B
C
Okay,
let's
start
so,
I
will
just
present
in
briefly
during
this
meeting
the
diff,
the
difference
between
the
previous
draft
and
or
focus
on
the
west
network
aspect.
So
basically,
we
now
have
a
section
which
deals
with
specificities
of
war
networks.
Instead
of
the
world
network.
We
don't
have
any
more
of
a
link
concept
because,
basically,
in
wire
network,
we
have
a
full
click.
C
Second
point
is
that
we
use
still
use
in
wireless
network
social
media,
so
we
have
very
low
fairness
because
we
have
a
capture
effect.
We
may
have
several
technologies
which
use
the
same
ism
band,
which
is
collapsing
together.
So
the
interest
is
that,
since
we
have
a
shell
medium,
we
have
a
single
transmission
which
is
able
to
cover
multiple
receivers.
C
C
So
that
in
mind
we
updated
also
the
operations
section
concerning
the
changes
which
are
specific
to
a
wireless,
more
or
less.
This
is
what
pascal
has
already
introduced.
So
this
is
how
we
may
piggyback
aggregate
the
packets,
the
control
information
inside
the
data
packet
to
reduce
the
volume
of
information
to
push
in
the
network.
C
We
have
also
to
verify
the
connectivity
and
that's
challenging
to
detect
that
some
resources
and
wider
assesses
are
in
common
for
different
flows.
So,
for
instance,
on
the
white,
we
have
two
different
cells
for
two
links,
so
the
link
a
b
has
the
first
transmission
opportunity
in
which
is
a
loan,
so
all
the
transmission
will
be
for
the
okay.
The
package
08
is
quite
small.
C
However,
we
share
the
same
radio
one
wave
with
another
link
for
the
another
transmission
opportunity,
and
it
may
be
very
challenging
to
detect
this
behavior
since,
for
instance,
the
second
cell
should
be
used
to
deliver
backup
purpose
forward
transmissions.
So
typically,
we
may
detect
this
problem
only
when
this
is
the
worst
case.
So
that's
bad
for
the
root
tracing
we
have
multipath.
We
may
have
multiple
technologies,
multiple
forwarders
with
opportunistic
forwarding
so
quickly.
C
It
may
be
very
complicated
to
explore
all
the
different
paths
are
changed
together
and
what
classical
proposed
as
the
bfd
approach,
or
we
may
collect
this
amount
of
image
information.
This
is
still
not
an
open
problem,
still
in
bounds
and
heart
of
bonds
for
the
administration
purpose,
we
tried
to
first
identify
the
voice
matrix,
so
we
have
still
to
noth
this
set,
so
wireless
metrics
perform
per
wider
channel.
So
that's
much
more
complete
and
that's
a
huge
volume
of
information
collect
and
more
or
less
we
don't.
C
We
are
not
anymore
interested
in
our
wedge
values.
We
we
have
other
worst-case
metrics,
such
as
max
burst
of
packet
losses,
because
it
has
an
impact
on
the
delay,
so
that
still
has
to
be
enriched
in
the
draft
and
last
but
not
least,
for
the
management
links.
Are
there
widow
c?
So
this
means
that
even
if
we
push
some
controlled
information,
even
the
data
packets
are
with
standalone
control
packets.
C
We
are
never
sure
that
they
will
be
received,
so
the
mechanisms
we
will
propose
have
to
be
consistent
enough
with
counters,
with
some
mechanisms
to
be
able
to
recover
from
pasture
or
total
lost
packets.
So
that's
still
to
be
addressed
for
our
application
and
emulation.
So
we
have
still
some
propositions,
but
in
wireless
networks,
overhearing
is
an
asset,
so
it
should
be
exploited
in
the
scheduling
process
and
in
the
rem.
C
We
must
collect
enough
information
to
be
able
to
exploit
this
property
and,
as
I
previously
presented
in
the
production,
the
water
conditions
are
very
time
variants.
So
this
means
that
the
network
must
react
very
of
very
quickly
to
the
changes,
because
we
have
some
obstacles.
We
have
some
external
interference
which
may
arise
in
some
specific
locations,
so
we
must
adapt
the
network
to
these
specific
conditions
very
fast,
so
it
was
a
very
short
update
of
what
we
modified
in
the
draft.
C
We
are
still
perhaps
missing
some
points,
so
please
wise
when,
in
the
next
version
we
have
still
to
remove
some
watermelon
parts
with
a
detroit.
That's
still
in
progress,
I
guess
that's
most
of
the
parts
70
of
our
job
has
been
done.
We
need
figures
and
we
need
to
be
also
much
more
exhaustive
for
a
list
of
metrics.
D
Thank
you
very
much
always
for
about
the
point
of
removing
what
is
redundant.
Maybe
you
could
flag
it
make
it
in
a
separate
section,
but
if
you
kind
of
remove
it,
you
make
your
document,
maybe
less
readable
and
then
again
it's.
I
would
like
the
document
to
be
consistent
and
then
once
we
are
ready
well
advanced,
we
make
sure
that
that
we
synchronize
it
with
with
the
net
document,
but
I
mean
removing
and
putting
pointers
may
be
hard
to
read
and
not
very
efficient.
At
this
moment,.
C
L
C
F
B
I
mentioned
earlier
concerning
the
oam
split
between
the
generic.net
oam
and
the
raw
specific
oam.
I
will
ask
the
question
on
the
list
because
that's
where
we
achieve
consensus,
but
the
proposal
is
to
keep
this
document
raw
specific
work
on
it.
In
parallel
with
the
debt
net
oam
draft
and
to
address
pascal's
comment,
I
believe
this
document
should
have
a
normative
reference
to
the
debt
net
oam,
so
that
the
so-called
redundant
parts
are
consistently
referenced.
G
I
I
think
implicit
in
pascal's
comment
is
a
general
question
that
maybe
in
front
of
the
working
group
is
what
is
the
scope
of
raw
is
raw
broader
than
debt
net,
or
is
law
supporting
that,
and
you
know,
I
think
this
is
like
the
second
or
third
time
we're
basically
hitting
that
same
point.
You
know,
I
think
that
that's
something
that
we
really
have
to
agree
on.
B
B
However,
when
we
have
addressed
that
problem,
I
personally
would
have
no
objection
to
arguing
for
a
re-charter
to
try
and
boil
a
bit
more
of
the
ocean,
but,
to
start
with,
I
think
we,
the
steer,
we're
getting
from
the
aeds,
and
I
think
deborah
is
on
this
call.
If
she
wishes
to
jump
in,
is
to
stay
focused
and
achieve
something
now,
and
that
means
limiting
our.
B
D
D
Initially,
I
was
exactly
like
that,
but
then
we
discussed
a
lot
about
this
party
access
thing
right
and
when
you,
when
you
do
the
multi-access
you
care
about
the
access
link,
which
is
the
wireless
one.
But
then
there
is
the
rest
of
the
way
and
when
you
want
to
get
feedback
at
layer
3,
you
get
feedback
for
this
from
the
destination
on
the
other
side
of
the
internet,
and
so
that's
when
this,
this
gray
zone,
where
some
hops
are
not
deterministic
and
do
not
speak,
that
net
comes
into
play.
D
B
A
B
B
I
believe
officially,
this
is
the
end
of
the
session,
but
I
am
very
happy
to
sit
here
and
listen
to
any
further
discussion
anyone
wants
to
have
otherwise.
Thank
you
very
much
for
attending.
Thank
you
very
much
presenters.
We
even
I
have
a
to-do
list
of
drafts
to
ask
for
adoption
on
the
mailing
list.
B
Please
use
the
mailing
list.
It
is
the
best
way
to
have
these
discussions
because
it
is
recorded
for
posterity.
So
in
15
years
time,
when
some
poor
implementer
tries
to
work
out
why
a
decision
was
made,
the
mailing
list
archive
still
exists
to
record
the
debate,
as
well
as
the
decision.
I'm
not
sure
if.
A
D
It's
competitive
related,
but
when
you
upload
the
minutes,
some
people
say
that
they
managed
to
upload
the
amd
file,
as
is
so,
if
you
just
copy
paste,
you
know
from
the
just
provided
the
link
to
go
to
the
code
dmd,
but
if
you
copy
paste
that
into
an
md
file,
some
people
said
they
managed
to
upload
that
directly
as
an
nd
file
and
presents
well.
When
I
tried,
through
the
tools
doing
some
exercises,
depending
on
the
platform
was
using
depending
on
the
browser
I
was
using.
D
The
mime
type
that
that
was
used
to
upload
was
different,
like
or
whatever
or
just
text,
but
the
the
the
tool
would
not
let
it
in
saying
it
doesn't
match
what
it
observes,
which
is
plain
text,
and
it
would
just
reject
for
some
security
reasons.
We
just
reject
the
empty
file,
in
which
case
I
tried
to
together
to
save
the
html
from
kodi.
So
cody
will
let
you
also
export
the
html
and
uploading
that
worked
just
you
know,
that's
my
current
experience,
but
some
people
said
they
managed
to
upload
dmd.
D
B
D
B
Well,
it's
it's
that's
a
question
for
the
working
group.
My
personal
opinion
is,
I
think,
there's
lots
of
great
content
in
there,
whether
it
lives
as
one
document
or
becomes
more
documents
if
it
gets
very
big
or
whatever
is
it
is
a
secondary
question.
I
think
it
has
value
for
the
working
group
to
work
on.
G
Yeah
I
mean
this
is
a
personal
statement,
obviously,
but
I
strongly
think
you
have
to
define
what
what
scope
you're
trying
to
solve
before
you
adopt
the
architecture.
It's
a
fundamental
question
and
you
know
I
pascal
I
I
get
where
you're
coming
from.
You
know
your
head's
in
wireless,
so
the
world
is
wireless,
but
you
know
that's.
G
G
G
That's
that's
a
different
metric.
You
know,
reliability
is
only
one.
Metric
availability
is
certainly
an
equally
important
metric.
I
mean
in
fact
I
think
it's
the
same
yeah.
It
all
goes
to
probability
of
loss
and
the
architecture
of
that
net
was
careful.
To
do
that.
You
know.
Pascal
was
a
deeply
involved.
Lead
author
maybe
go
out.
I
don't
know.
E
F
G
D
What
I
don't
know
is
if
this,
because
people
are
these
discussions,
they
came
in
with
this
access
program
and,
and
it
kind
of
seems
to
be
very,
very
important
in
the
wireless
world
most
of
the
wireless
is
not
mesh.
Most
of
the
wireless
is
access,
and
so,
if,
if
the
group
focuses
on
mesh
within
every
hub
being
aware,
then
that's
not
a
very
practically
useful
thing.
G
From
an
abstract
case,
that's
that's
not
much
different
than
a
wired
access
problem
where
you
have
two
different
paths
that
give
you
different
service
and
different
costs
in
them.
You
know
why.
Why
is
the
the
general
selection
problem
at
the
access
a
raw,
specific
problem
now
there's
the
generic
problem
that
you
want
to
cover
for
any
time
network
type
and
then
add
in
the
case
of
the
wireless
consideration:
okay,.
F
B
F
B
G
D
Yeah
I
mean
we've
been
back
and
forth.
I
remember
norma
mic
saying:
let's
exclude
where
is
just
too
complicated,
and
so
so,
even
if,
if
the
broad
domain
as
well
as-
and
I
don't
I'm
very
happy,
it
does
because
I've
been
pushing
for
that
all
the
time,
but
the
methods
that
the
work
and
the
mind
of
people
is
really
for
those
very
reliable,
stable
links,
and-
and
so
that's
why
we
have
this
this
basically
overall.
G
D
H
B
G
Now
I
don't
want
that
one,
but
I
do
want
to
get
into
that.
The
comment
I
was
going
to
make
is
to
sort
of
consistent
with
what
I
think
deborah's
saying
is,
I
think,
you're
in
scope
for
for
net,
but
there
are.
There
are
absolutely
wireless,
specific
considerations
that
you
should.
You
know
that
we
need
to
cover
so.