►
From YouTube: IETF104-PAW-20190328-1350
Description
PAW meeting session at IETF104
2019/03/28 1350
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
And
so
this
is
the
power
non
workgroup
forming
boss
about
predictable
and
available
wireless.
This
is
an
official
ITF
meeting,
so
all
the
best
practices
that
you're
very
well
off
apply
here,
in
particular
Mississippi
1554,
for
the
code
of
conduct,
so
please
be
am
able
to
to
each
other
and
obviously
PCP
79,
which
deals
with
IPR.
So
if
you're
aware
of
IPR
about
something
which
will
be
discussed
today,
please
let
it
be
known
immediately
or
to
the
chairs.
At
the
end
of
this
meeting.
A
As
a
reminder
we
have,
we
are
relied
on
mythical,
meaning
that
a
minute
will
be
taken.
Presence
will
be
loud.
You
will
be
filmed
so
when
you're
actually
presenting
please
stand
on
the
red
cross
behind
the
mic,
so
people
are
Michiko
will
be
able
to
see
you.
We
are
taking
the
minutes
on
the
etherpad.
The
link
is
provided
on
this
page.
Even
if
you
don't
plan
to
take
minutes,
please
join
the
iPad
that
may
help
you
see.
A
Then
again,
if
you
have
bad
mythical,
we
have
like
three
or
four
three
presentations
which
will
be
done
over
Michiko.
We
have
a
mailing
list,
which
is
foul
I,
said
well
say
at
the
end
of
this
meeting.
It
won't
be
the
final
name
for
this,
so
if
you
have
not
registered
yet,
please
wait
for
the
end
of
the
meeting
for
the
announcement
of
the
new
name,
for
whatever
we
are
doing,
which
will
not
be
bad.
A
So
the
surprise
is
to
the
end.
With
this
we
have
a
very,
very
tight
agenda.
You
will
see
at
the
sessions
are
5
or
10
minutes
each,
so
we
have
to
rush
through
them.
So
that's
what
I'm
doing
right
now
observe
we'll
be
going
through
the
scope.
What
we
intend
to
do,
which
is
the
general
objective
of
this
meeting
and
of
the
people
in
this
room,
will
go
through
a
number
of
Tuesday's
will
just
show
you
a
number
of
them.
There
are
other
use
cases
which
were
presented
in
other
venues.
A
For
instance,
there
are
use
cases
in
the
dead
net
use
case
document,
which
is
edited
by
Ethan
here.
So
please
go
and
visit
this
document
as
well,
and
there
are
the
use
cases
they're
interesting
news
cases
which
were
presented
at
the
I
Triple
E
for
a
group
that
was
called
FTA
at
the
time
for
real-time
application,
in
particular
use
cases
in
the
context
of
gaming
real
time
gaming.
So
all
those
use
cases
in
the
end
will
end
up
in
in
this
particular
document.
A
Then
we
go
through
the
technologies
because,
if
not
have
technologies
to
account-
and
there
is
no
point
in
meeting-
but
we
kind
of
know
that
there
are
a
number
of
technologies
that
are
now
showing
up
for
which
a
variable
unpredictable.
These
can
be
obtained,
and
so
we'll
go
through
a
number
of
them
and
see.
If
we
can
work
with
them
as
a
working
group,
then
we
look
at
the
first
routes
which
were
published
under
Pao,
so
there
are
two
of
them.
A
There
is
a
third
one
which
is
we
under
beer,
but
which
is
also
of
interest
for
this
group
and
fernette.
Finally,
we'll
talk
about
the
next
steps,
which
is
mostly
the
first
draft
of
charter,
that
we
can
build
right
now
and
and
well
announcing
the
name
of
whatever
we
are
doing
next,
which
will
not
be
powers,
I,
say
still
a
secret,
so
scope
of
the
work.
Basically,
there
was
this
name
around
about
deterministic
networking,
it's
even
in
in
kind
of
in
the
dead
net.
Acronym
people
in
the
wireless
world
tend
to
avoid
that
term.
A
So
we
try
to
express
those
qualities
without
using
the
term
deterministic
and
that
we
are
predictable
on
available.
Wireless
came
yet,
but
at
the
end,
it's
about
machine
to
machine
communication
like
it's
about
very
repeatable
actions.
It's
about
removing
some
elasticity
so
that
machines
can
have
automated
system
using
those
networks.
A
What
we
can
do
in
a
network
like
like
Wireless,
is
control
the
time
of
emission.
If
we
have
access
to
a
Mac
file
which
which
allows
for
that
speaker,
lemak
files
like
ACH
or
FDMA,
we
will
allow
you
to
all
the
time
of
transmission
as
opposed
to
CDMA.
If
you
have
a
technology
like
that,
then
you
can
program
when
the
transmission
will
happen
and
you
can
control
the
time
of
delivery.
So
that's
one
thing
we
can
do
now
with
some
of
those
technologies
control
the
time
of
delivery.
What
we
cannot
do
is
control.
A
A
So
we
cannot
control
the
delivery
ratio,
but
what
we
can
do
is
use
all
the
mechanisms
that
we
have
at
hand
on
the
wireless
space
to
optimize.
That
ratio
and
avoid
many
losses
in
a
row
in
particular
the
mitigations
depend
on
the
threat.
So
that's
why
it
takes
all
forms
of
diversity,
frequency,
diversity,
time,
diversity,
space,
diversity,
being
diversity.
There
are
many
forms
of
diversity,
coding
diversity,
which
can
actually
each
in
its
own
way
help
alleviate
the
causes
of
frame
loss.
A
So
at
the
end
of
the
day,
everything
quote-unquote
deterministic
boils
down
to
being
able
to
schedule
your
network
and
schedule
your
transmissions.
The
reason
why
your
schedule
is
to
be
able
to
reserve
the
resources
make
sure
you're,
never
out
of
buffers
or
bandwidth
rights,
or
anything
like
that.
So
it's
all
about
resource
reservation.
A
In
the
end
with
that
on
why
our
network
and
the
debt
net
experts
in
this
room
will
tell
you
that
we
can
provide
the
high
delivery,
we
can
avoid
congestion
laws
pretty
much
what
we
call
congestion
rules
and
wires,
which
is
really
collisions
inside
the
device
and
shoes
getting
for
something
like
that.
We
can
allow
much
higher
ratios
of
transmission
of
critical
flows
like
the
highest
cost
and
reach
sixty
to
seventy
percent
of
your
traffic
and
we
deliver
within
a
bounded
latency.
That's
read
the
critical
aspect
of
those
networks.
A
We
can
do
that
because
we
schedule
the
network.
Those
benefits
exist
in
while
in
wires
they
also
exist
exist
in
Wireless.
Schedule
provides
additional
benefits
in
wireless.
One
of
the
key
benefits
we
can
obtain
is
avoiding
the
empty
the
gaps
of
time,
such
as
ifs
in
CDMA,
where
there
is
no
transmission.
If
you
schedule
every
transmission,
you
know
exactly
when
it
happens,
and
there
is
no
no
reason
to
stay
silent
between
transmissions,
critical
to
IOT
and
machine-to-machine
relays.
A
We
can
schedule
when
you
send
and
your
receive
meaning
that
the
rest
of
the
time
the
device
can
be
slipping,
and
this
is
how
battery
optimization
is
obtained.
If
you
have
to
screen
the
network
periodically
to
see
if
there
is
a
transmission
for
you
or
if
you
stay
always
on,
then
your
battery
will
deplete
rapidly.
A
On
the
other
hand,
if
you
have
this
IOT
device
that
must
live
on
battery
for
a
year
or
two,
then
it
must
have
a
very
deep
sleep
schedule,
while
most
of
the
time
99%
the
time
it's
not
on
meaning,
it
cannot
receive
any
message
at
that
time,
so
it
must
be
scheduled
to
know
when
to
receive
messages.
At
the
same
time,
the
sender
must
be
scheduled
and
if
only
scheduled
transmissions
happened
a.m.
to
control
most
of
the
emitters,
then
you
can
also
remove
most
of
the
interferences.
A
We
can
never
say
all
in
particular
in
the
unlicensed
band,
but
at
least
we
can
reduce
the
interference
traumatically
if
we
can
tell
most
of
the
devices
in
the
network
not
to
sell
at
the
time
of
a
scheduled
transmission
for
a
deterministic
flow.
Now
we
want
to
achieve
this.
Determinism
could
include
deterministic
properties.
A
How
we
can
achieve
that
will
have
to
be
different
from
how
we
do
it
on
wires
and
that's
why
we're
here
we
have
to
to
understand
the
particular
properties
of
wireless.
We
have
to
leverage
those
properties
and
be
able
to
program
that
into
the
network
on
the
multi
of
network,
to
be
able
to
obtain
the
capital
capabilities
we
want
on
wireless
and
in
a
good
part
of
the
presentation.
Today
will
be
about
understanding
what
those
properties
are
and
see
how
we
can
program
them
into
a
schedule.
A
A
Even
if
you
stay
at
the
same
place,
the
radio
link
has
to
be
reevaluated
all
the
time,
meaning
that
the
routing
that
you're
building
on
top
of
it
may
need
to
be
reevaluate.
Yet
you
can't
rebuild
your
routes
every
second,
so
you
have
to
think
about
separating
what
you
do
at
the
writing
level
and
what
you
do
at
the
falling
level
at
the
writing
level.
You
need
to
enable
many
ways
to
get
there
and
the
defaulting
level.
A
You
must
decide
out
of
all
those
possibilities
which
is
the
one
that
gives
you
the
best
results
at
this
particular
time.
This
is
why
om
instantaneous
understanding
of
the
properties
of
your
path
is
so
important
to
us.
It's
important
to
that
net.
It's
a
lot
more
important
to
us.
We
Merson
permanently
you
reevaluate
the
quality
of
the
possible
paths
that
were
using
and
use
the
one
that
works
best.
If
we
use
too
many
of
them.
We
are
interfering
too
much
with
the
rest
of
the
world.
A
Then
we
are
wasting
energy
if
we
don't
use
enough
we're
losing
packets,
so
that
needs
to
be
tightly
evaluated
and
and
recomputed
all
the
time
that
cannot
be
done.
You
know
from
a
controller
every
second,
we
have
to
do
that
at
the
falling
time.
So
that's
why
I
am
is
very
critical
to
us
and
with
this
will,
if
you
have
any
question
about
our
scope,
this
is
pretty
much
where
we're
going.
B
A
Are
at
least
after
specifying
what
can
be
scheduled,
we'll
have
to
work
with
you
know
the
ASG,
the
other
chairs,
etc,
to
decide
exactly.
If
there
is
data
model
to
be
built
in
which
working
group
it
will
be
finalized,
but
at
least
we
are
the
source
for
what
type
of
information
goes
into
that
data
model?
A
Okay,
because
it's
a
very
specific
special
skill
and
you'll
see
that
through
the
presentation
today
to
understand
what
can
be
scheduled
and
how
and
which
properties
are
useful
in
which
radio
and
those
properties
are
are
you'll,
see
on
some
of
the
slides.
They
are
not
necessary,
classical
if
you're,
coming
only
from
the
wire
space.
No.
B
A
Right,
you
would
see
the
same
from
3gpp,
but
we
can
at
least
probably
ask
them
a
certain
service
and
we'll
see
how
we
can
do
that,
but
ask
for
a
certain
service
and
we'll
get
back
from
them.
What
we
got,
probably
they
will
have
to
schedule
it
inside
our
network
for
that
particular
hub,
and
then
we
will
have
to
build
a
multi
hoc
network.
Based
on
that,
we
don't
specify
exactly.
A
We
will
have
to
be
abstract
right,
because
the
chassis
H
is
not
just
an
OFDM
a
we
have
to
do
something
which
works
for
both,
but
at
least
LTE
and
the
yaks.
They
look
very
much
the
same
guitar,
both
HMA,
so
we
can
probably
go
around
that
I
mean
an
abstraction
or
TDMA
FDMA.
That's
the
beginning
of
it.
C
And
Carlos
one
others
from
university
concern
and
I'm
presenting
this
on
behalf
of
my
cold
sores.
So
this
is
basically
about
two
sorry
present
some
use
cases
for
for
pal.
This
presentation
is
not
meant
to
be
exclusive
in
the
sense
that
there
are
all
of
you
use
cases
that
we
are
considering
already.
So
these
are
some
examples
to
try
to
provide
a
motivation
for
for
the
need
of
top.
So
for
each
of
the
use
cases.
I
will
briefly
summarize
the
use
cases
scenario.
C
Then
I
will
try
to
identify
some
specifics
for
that
use
case
that
make
it
different
from
the
others
then
justify
a
bit
the
need
for
wireless
in
this
use
cases,
although
I
think,
would
be
pretty
clear
when
we
describe
the
use
cases
and
then
try
to
identify
some
specific
demands
or
requirements
from
each
of
the
use
cases
for
potential
work.
That
power
will
be
doing
so,
let's
start
with
the
first
one
they
are
listed
in
no
particular
order,
so
the
first
one
is
amusement
park.
So
I
guess
you
we
have
an
idea
of
that.
C
We
have
an
attraction
park
where
we
have
attractions.
Those
attractions
have
sensors
and
actuators
that
need
to
provide
different
data
among
them
and
to
a
potential
controller
that
is
in
a
remote
location.
We
may
also
have
CCTV
cameras,
recording
and
doing
some
real-time
processing.
We
may
have
people
wearing
wearable
devices
for
entity
tracking
and
all
these
things.
So
basically,
we
have
an
environment
which
is
large
scale,
and
that
is
controls
with
multiple
type
of
networks
that
need
to
interact
among
themselves.
So
this
is
basically
the
mini
specific
characteristic
of
this
use
case.
C
That
is
a
multi
scale
topology.
So
we
have
local
area
networks
for
some
perform.
A
real-time
sensors
and
actuators
will
have
wearable
devices
and
we
need
to
have
the
the
global
the
connectivity
between
mobile
systems
in
the
park.
So
these
are
kind
of
a
specific
things
of
this
case.
Why
do
we
need
Wireless
here?
Well,
finish
is
clear:
what
less
is
chip
we
need
on
large
area
to
to
cover,
so
we
need
to.
This
will
not
be
feasible
with
wire
connectivity.
C
Then
we
also
have
devices
that
I'm
a
while,
not
only
on
attractions
but
by
the
users
themselves,
and
we
need
to
provide
connectivity
between
many
different
systems
for
some
both
for
maintenance
purposes.
So
we
need
wireless
here.
So
what
do
we
need?
What
we
require
from
power
from
this
use
case?
Well,
we
need
to
support
different
kind
of
traffic
at
really
nice
traffic,
with
different
criticality
and
different
requirements.
C
We
to
be
able
to
a
schedule
to
support
IP
traffic
over
a
set
of
different
technologies
and
providing
providing
quality
of
service
with
different
SLA.
So
this,
basically
the
main
the
main
requirement
for
this
use
case,
which
we'll
see
that
is
also
a
common
thing
that
we
will
see
in
other
use
cases.
So,
let's
go
to
a
second
one.
Second,
one
is
webOS
for
industrial
applications
and
consuming,
for
example,
a
factory.
There
is
many
factories
and
kind
of
goods,
so
there
will
have
different
things
and
basically
we
have
a
controller.
C
C
So
basically,
we
need
to
have
this
network
for
controlling
the
the
different
tools
in
the
in
the
factory
and
depending
on
the
industry
specific
thing,
the
the
demand
for
Polly
traffic
transmission
comes
from
few
hundreds
of
milliseconds
to
adjust
a
few
milliseconds,
but
in
all
the
cases,
what
we
need
is
a
flow
of
packets.
That
is
kind
of
quote.
Deterministic
quote
in
the
sense
that
the
losses
and
the
delay
has
to
be
minimized.
C
And
then,
in
addition
to
this,
we
have
hosted
the
monitoring
and
the
end
Nasik
network
that
is
basically
used
to
get
data
that
can
be
used
to
optimize
the
network
for
sample
using
machine
learning
technologies
and
this
kind
of
things,
and
it's
important-
that
this
network
shouldn't
be
mixed
with
traffic.
For
this
part
with
the
control
the
process
control
loop
network,
then,
if
for
water
as
well,
I
guess
it
is
also
clear
there
are
male
parts
or
wires
I'm,
not
good
to
hear,
and
even
if
we
could
use
wires.
C
That
will
be
very
expensive
and
even
if
we
have
a
baby,
a
wire
infrastructure
in
place
for
the
control
part
for
the
monitoring
part,
we
need
to
separate
those
two
networks,
so
we
need
to
deploy
something
and
that
should
be
Wireless.
So
what
do
we
need
for?
What
do
we
demand
for
Pao
in
this
case?
So
we
need
to
be
able
to
support
traffic
legacy
traffic.
C
Let's
say
in
addition
to
the
flows
of
liquid
displaced,
our
treatment
and
again,
we
need
to
be
able
to
set
up
a
flow
with
abundant
latency
between
the
different
points
in
this.
In
this
case,
if
we
move
on
to
another
use
case,
this
is
the
professional
LD
on
video
and
for
sample.
We
may
have
announced
many
speakers
and
CCTV
cameras
deployed
in
transportation.
C
Systems
like
train
stations,
airports
in
theme,
parks
and
here
the
specific
thing
is
that
we
need
to
support,
uninterrupted
stream
for
the
video
and
for
the
album.
So
in
this
case
we
cannot
cope
with
network
or
by
transmitting,
because
we
need
to
have
an
uninterrupted
stream,
and
another
key
characteristics
is
that
we
need
to
synchronize
the
view
in
the
video
with
very
specific
or
very
constrained
requirements.
So
this
is
also
something
specific
of
this
use
case.
So
what
do
we
need?
C
Well,
we
need
again
to
support
different
kind
of
traffic's
with
different
kind
of
keywords,
requirements,
and
we
need
to
be
able
to
provide
the
content
with
bounded
lowest
possible
latency,
for
the
reasons
that
we
we
saw
before,
and
also
to
support
multipath,
mainly
for
resiliency
purposes,
to
avoid
these
natural
errors
that
we
or
to
not
to
to
cope
with
networkers
in
a
way
that
we
don't
need
to
do
any
kind
of
retransmission.
As
we
saw
before
then.
An
early
news
case
is
about
UAVs
and
money.
C
They
are
vehicles
or
drones,
which
are
becoming
very
popular
nowadays
and
that
are
can
be
used
for
many
different
purposes,
like
surveillance
or
even
transportation
of
his
mall
Goods,
and
these
guys
are
equipped
with
different
kind
of
wireless
technologies
like
cellular
or
Wi-Fi
kind
of
connectivity
among
others.
What
is
a
specific
of
this
use
case?
The
specific
thing
is,
in
addition
to
the
connectivity
between
the
guy
and
the
drone
and
the
central
control.
C
The
need
for
webOS
I
think
is
clear.
We
cannot
wire
Navy,
so
that's
easy
and
worry
would
be
the
specific
ones
from
this
case
for
top
well,
we
need
to
be
able
to
automatically
or
in
a
self
kind
of
configure
way
set
up
the
network,
because
the
network
itself
is
composed
by
the
UAVs.
So
we
need
to
have
some
kind
of
circumcision
capabilities.
C
We
need
to
support
a
thoroughly
nice
traffic
again
from
video
to
synchronization
among
different
UAVs,
and
we
are
considering
this
specific
case
in
which
we
have
a
service,
a
function
that
is
the
composer
in
smaller
parts
that
are
hosted
by
the
different
UAVs.
We
need
to
support
the
different
requirements
for
the
different
links
between
these
functions.
That
may
be
different
for
the
for
the
different
links
that
compose
a
given
service
and
the
last
one
is
the
edgy
robotics
control,
which
is
a
bit
similar
in
the
sense
that
we
have
robots
that
are
controlled.
C
C
The
need
for
one
less
eye
again
is
very,
very
easy
to
see
mobile
devices.
Do
we
need
we
need
wireless
and
even
if
we
could
wire
those
robots,
the
kind
of
the
Prime
Minister
that
we
have
in
mind,
for
example,
in
a
shopping
mall
to
do
cleaning
or
deliveries
and
goods.
In
those
cases,
we
cannot
have
wires
with
the
ropes,
so
we
need
to
do
it
wirelessly.
C
So
what
do
we
need
here
again?
We
need
to
support
to
reduce
traffic
types
of
traffic
from
the
robot
to
the
controller
among
the
robots
and
again
it
will
decompose
functions
that
are
run
or
are
collectively
performed
by
the
robots
themselves.
We
need
to
support
different
kind
of
requirements
for
any
different
type
of
links
that
we
will
be
having
this
is
scenario,
so
this
is
a
very
brief
summary
of
five
years
cases.
C
One
key
conclusion
here
is
that
we
have
different
use
cases
that
determine
different
wireless
connectivity,
features,
recording
predictability
and
availability,
and
these
are
just
some
use
cases,
but
are
more,
and
we
are
really
working
on
some
other
use
cases,
for
example,
for
wireless
interactive
gaming.
This
is
one
example.
Where
are
a
few
others,
so
first
question
would
be
do
we
should
we
continue
documenting
these
use
cases
additional
use
cases
and
also
trying
to
provide
a
better
characterization
of
the
requirements
that
this
each
of
these
cases
process
into
the
power
potential
work?
C
D
My
question
was
I
mean
because
what
I
understood
cope
was
to
come
up
with
some
new
kind
of
scheduling
mechanisms
in
the
Mac
layer.
So
a
lot
of
these
use
cases
can
be
covered
with
five
GNR
I
suppose,
because
it
offers
you,
like
hundreds
of
microseconds
delay,
so
I
mean
it.
Has
that
been
considered
or
I
mean?
Are
we
considering
if
it's
cellular,
probably
that
would
be
choice
so.
C
A
If
I'm
playing
that
we
can
do
everything
with
a
single
up
cellular,
the
answer
would
be
probably
not.
We
are
looking
at
everything
which
has
to
deal
with
multi-hop
networks.
If,
if
a
single
hub
radio
network
can
do
the
trick,
it's
like
you
know,
if
you
can
do
it
at
layer,
2,
ETS
n,
then
it
might
be
that
that
net
doesn't
have
much
to
do
same
thing
here.
If
you
can
do
everything
with
1/2
player2,
then
you're
happy.
A
We
don't
need
us,
but
if
you're
building
a
network
which
requires
properties
of
our
multiple
Hopf,
some
of
them
wireless,
then
probably
we
need
to
be
able
to
specify
that
that
path
end-to-end,
they
don't
provide
to
the
different
layer
tools,
the
property
that
we
expect
from
them
for
about
hello
heart
and
be
able
to
join
the
packet
from
one
hub,
which
is
this
type
of
link
to
this
other
heart,
which
is
this
other
type
of
link.
So.
A
There
is
a
real
difficulty,
a
real
tension
between
adult
mobile
in
the
one
hand
and
quote-unquote
determinism
on
the
other.
There
are
things
that
can
be
done
and
I
hope
that
you
know
we'll
see,
draws
about
managing
a
control
mobility
that
can
still
be
deterministic,
but
we
certainly
will
not
start
with
mobility
or
hey
doc.
Okay,.
A
You
could
say
that
if
you
know
something
like
a
factory
or
something
like
that,
you
have
enough
control
on
the
mobility
of
the
devices
that
the
network
that
you
form
doesn't
change
too
much.
If
the
generic
case
I
mean
this
very,
very
complex
problem,
because
there
is
this
tension
between
programming,
understanding,
something
and
everything
moving
over
time.
Okay,.
E
E
E
A
Could
be
a
very
important
work
for
this
group
and
it
will
not
express
the
expressed
in
never
lose
a
packet
even
wires.
Don't
do
that
and
the
10
blah
is
usually
not
very
useful,
either.
What's
very
useful
in
applications
them
aware
of
is
more
like
MTBF
mean
time
between
fault,
for
instance,
if
you,
if
you
operate
a
factory,
you
get
this
control
loop
and
you
lose
one
packet.
It's
never
a
problem,
because
you
expect
that
you
will
lose
one
packet,
that's
part
of
the
game.
A
Now,
if
you
lose
four
packets
in
a
row,
then
the
robot
concludes.
There
is
a
loss
of
connectivity
and
it
will
go
to
emergency
stop
so
clearly.
The
mtbf,
for
this
particular
case
is
never
for
right.
So
this
is
the
way
quality
of
service
that
we
want
to
obtain
will
be
up,
will
be
probably
determined,
but
it
depends
on
the
use
case,
but
for
for
everything,
automation,
machine
to
machine,
it's
usually
expressed
in
two
min
to
a
mean
time
between
fault
and
obviously,
you've
got
jitter
boundaries,
you
get
latency
boundaries,
etc.
E
G
H
It
sounds
like
you're
saying,
if
you're
not
losing
packets,
how
can
you
guarantee
that
you're
going
to
have
the
packets
all
arrived
at
the
end
and
I?
My
understanding
is
that
you're
in
a
wired
system,
redundant
paths
are
optional,
but
in
this
kind
of
system
redundant
paths
are
an
absolute
given.
So
it's
given
that
you're
gonna
lose
some
packets,
but
it's
also
given
that
there's
going
to
be
redundancy
now.
E
I
A
Actually,
you
use
to
welcome
you
come
and
write
the
draft
about
this,
because
that
is
a
key
question.
It's
I'm
not
joking
at
all,
that's
a
key
question
and
there
is
a
lot
of
work
that
was
done
in
that
area
like
20
25
years
ago
and
starting
with
key
with
acronyms,
like
MTBF
I'll.
Take
you
a
long
way
to
finding
those
papers.
J
A
J
A
That's
interesting
case:
we
have
not
listed
it
yet
in
the
use
cases.
I
hope
we'll
be
doing
that,
because
a
large
weight,
large
piece
of
the
weight
of
a
car
comes
from
the
copper.
That's
used
for
wiring
a
large
amount
of
the
complexity
of
building
a
car,
the
cost
of
living.
That
car
is
also
all
this
shape
that
you
have
to
build
where
you
lay
out
all
the
wires.
A
I
H
In
debt
net,
we
started
out
having
some
wireless
use
cases
and
in
order
to
simplify
or
constrain
the
problem.
As
we
discovered
that
the
ways
in
which
deterministic
behavior
is
implemented
in
wired
versus
wireless
systems,
we
decided
to
split
off
the
wireless
piece
of
it
and
to
handle
it
separately
at
some
time
in
the
future,
and
this
is
nominally
that
time
in
the
future.
When
we're
deciding
to
actually
look
at
the
wire
king,
the
wireless
cases,
but
in
debt
net,
we
explicitly
decided
to
to
not
deal
with.
I
K
It
would
be
following
on
to
the
previous
question
sort
of
understanding
the
feasibility
of
this,
because
it
sounds
a
bit
hard
to,
even
though
you
have
a
bunch
of
diversity,
bouncing
things
off
of
objects,
whatever
right.
Guaranteeing
that
you
will
never
see
for
narrow
seems
hard.
So
is
there
sort
of
some
research
that
shows
the
feasibility
of
this?
It
would
be
good
to
sudden
some
pointers
to
the
list
of
the
state-of-the-art
there.
A
K
L
A
K
It
down
in
the
earthquake
category,
whatever
probabilities
you
operating,
but
so
the
other.
My
other
question
is
and
that
maybe
you'll
get
to
that
later
in
case
all
sit
down
and
sort
of
what's
the
intended
architecture
here,
because
it's
the
intended
architecture
that
there
will
be
some
sort
of
a
are
cute
layer
that
will
know
about
these
qualities.
The.
F
C
A
Understand
from
the
discussion
that
probably
will
need
a
document
just
to
formalize
that
at
least
point
on
existing,
often
how
you
measure
the
errors,
etc.
I
don't
know
if
that
can
be
done,
that
that
net
come
on
now
etcetera
because
you
have
the
same
characterizations
to
make,
but
I
understand
it's
needed
because
just
claiming
10,
minus
5
or
10
minus
10
doesn't
have
not
okay.
With
this,
we
really
need
to
move,
because
now
we
have
lost
a
lot
of
time,
not
lost
consumed.
A
lot
of
time.
J
Hi
I'm
Lou,
burger
I'm
gonna
be
talking
a
little
bit
about
debt
net.
It's
a
working
group
that
I
co-chair
with
Jana
safar
costs
here
turns
out
I
also
co-chair
traffic
engineering
architecture
and
signaling
working
group
T's,
which
is
somewhat
related,
so
we
may
I
may
bring
in
a
little
of
that
next
slide.
Please!
Oh.
M
J
About
that
so
I'm
gonna
take
a
step
back.
This
is
a
you
know.
You
can
read
this
or
look
at
the
Charter,
but
I'm
gonna
take
a
step
back
and
just
talk
about
what
debt
net
is
so.
Debt
net
is
all
about
ensuring
that
we
have
guaranteed
delivery
of
packets
within
a
guarantee
time
window
and
guaranteed
delivery
means
we
look
to
mitigate
loss
II.
We
want
to
take
advantage
of
the
links
that
can
most
best
support
the
requirements
of
a
service,
so
we'll
certainly
avoid
loss
in
the
cases.
J
We
can't
avoid
loss
right
now,
we're
doing
one
plus
one
protection
for
those
in
the
transport
world,
packet,
replication
and
elimination
for
those
who
don't
know
that
term
and
so
we're
doing
redundant
traffic
delivery.
That
is
what
our
solution
is
from
an
architectural
standpoint.
Debt
net
allows
for
anything,
including
like
network
coding
and,
in
fact,
that's
explicitly
called
out
in
the
architecture
document.
J
We
also
are
very
concerned
about
latency
and
we
calculate
the
latency
across
the
networks
to
ensure
that
packets
for
a
particular
service
or
a
particular
flow
are
delivered
within
the
context
of
that
requirement.
We
are
a
multi
hop
solution
we
are,
we
are
just
like.
Ip
is
multi-hop
going
across
multiple
subnet
sub
network
technologies.
That's
what
that
net
is
focused
on
I'm,
sorry
to
counter
the
chair
about
a
document
that
he's
an
editor
on,
but
we
still
have
wireless
in
our
use
case
document.
A
J
A
Short
answer
is
trying
to
integrate
deeply
with
the
radio
layers
would
be
even
more
difficult
at
that
Bette
net
trying
to
integrate
deeply
with
DSL.
So
that
would
be
for
me
boiling
the
ocean
and
that's
for
now.
What
I'm
after
is
pure
inheritance
from
60
and
dead
net,
and
just
adapting
that
spawning
really
into
the
wireless
most
specific
use.
Cases
like
extending
in
you
know
death
nets
into
that
world,
benefiting
from
what
you
did
and
pushing
it
harder
for
the
wireless.
So.
J
What
I'm
hearing
what
I
would
call
that
as
an
integrated
sorry,
not
an
integrated
approach,
but
more
of
a
layered
approach.
We
do
that
a
lot
in
the
ITF
and
I
can
talk
about
that.
A
moment
of
how
we
do
that
in
other
working
groups,
and
that's
great.
That
makes
a
lot
more
sense
to
me
than
trying
to
optimize
again
talking
from
the
wireline
perspective,
trying
to
optimize
IP
and
Ethernet
networks
together
at
the
same
time,
so
that
that's
actually
a
really
good
answer.
So,
let's
moving
forward,
we
have
a
charter
it.
J
We
cover
the
architecture
where
we're
we've.
Actually,
we
have
a
data
plane
definition,
the
we
did
the
hard
work
on
the
data
plane
about
a
year
ago
and
we've
been
having
a
little
trouble
documenting
it,
but
we
have
agreement
on
what
it
is
where
we
think
we've
sort
of
broken
through
and
so
looking
forward
to
data
plane
documents
kicking
out
soon.
We
have
an
architecture
document,
that's
kicking
out,
so
we're
making
some
good
progress
on
those.
J
We
right
now
are
stopping
at
models
for
control
of
a
debt
net
and
so
again
a
multi,
hop,
Network,
and
so
the
model
of
control
is
stopping
at
a
yang
definition,
whether
we
do
control
plane
in
the
future
or
have
other
groups
through
the
control
plane.
We'll
figure
that
out.
Let's
finish
this
piece
of
work
and
we'll
go
from
there,
but
again
our
Charter
is
the
the
multi
hoc
network.
J
Debt
net
fits
into
basically
a
family
of
working
groups
that
are
related
on
different
traffic
engineering
problems.
Debt
net
differs
from
what
we
were
seeing
in
MPLS
or
antes
is
in
that
it
has
a
much
higher
delivery
requirement
than
we
traditionally
need
to
support
in
internet
technologies.
Even
we're
doing
traffic
engineering
solutions
in
the
internet,
so
we're
gonna
coordinate
with
other
groups,
providing
solutions,
the
one
of
the
two
of
them.
That
really
matter
is
this.
J
This
T's
working
group
that
I
brought
together
and
C
camp
that
we'll
hear
in
a
moment
T's
is
working,
is
worried
about
the
overall
architecture.
C
camp
is
worried
about
the
binding
of
that
overall
architecture
to
specific
technologies,
and
maybe
that's
a
parallel
here
I'm.
Maybe
that's
how
we
could
split
things
between
these
two.
If
we
form
two
groups,
maybe
that's
how
we
split
it
is,
is
you're
more
about
looking
at
how
to
map
that
that
down
to
to
the
radio
layers-
and
maybe
maybe
there's
enough
there
I,
don't.
J
So
that
that
actually
fits
in
very
nicely
what
we've
done
in
other
groups,
yeah
I
think
there's
a
lot
of
coordination
that
has
to
happen
there.
We
can
talk
about
value
as
she
well
understands
the
coordination
how
to
make
that
that
work
and
how
we
made
it
work
with
T's
and
C
camp
and
MPLS
and
PCE
and
I
think
I'm
not
sure
now
spring
and
beer
by
the
way.
It's
a
it's
a
lot
of
fun.
J
One
thing
we're
not
working
on:
we
are
from
the
network
layer
down
and
I.
Think,
maybe
that's
why
we're
in
the
routing
area,
but
we
live
in
the
routing
area,
certainly
transport
protocols
and,
above
that
those
are
all
out
of
scope.
Oh
yes,
so
I
I
forgot
a
couple
of
other
in
order
to
make
this
all
work,
there's
actually
a
lot
of
groups
we're
coordinating
with
there's
a
list
here
I
charge
of
how
we
coordinate,
but
really
this
is.
J
A
I
may
say
you
have
listed
six
this
year,
60
the
the
point
being
that
six
dish
will
not
actually
work
on
that
net
piece.
It
will
probably
end
very
soon
and
what
we
do
here
would
be
like
the
spin-offs
of
six,
maybe
in
more
appropriate
area,
to
specialize
on
the
interaction
with
that
net.
Yes,
so
it's
not
the
competition
two
to
six
dish.
It's
actually
the
continuation
of
six
dish
with
different
means.
Okay,.
J
We've
had
discussions,
sort
of
with
the
chairs
with
the
idea
thing:
what's
gonna
happen
next,
when
we
start
needing
to
do
control
playing
when
we
start
needing
to
map
to
different
technologies,
and
what
we've
viewed
is
debt
net
might
be,
will
largely
be
doing
requirements
and
then
shipping
off
that
the
details
would
be
happening
in
the
existing
working
groups
that
own
the
protocols.
So,
for
example,
there
would
be
work
going
on
in
T's
if
we
were
going
to
do
a
distributed
protocol
that
distributed
control
plane
or
there
would
be
work
in
it.
J
Maybe
in
CNC
camp
after
we
complete
the
initial
set
of
mapping
of
debt
net
to
different
technologies.
Right
now
we're
doing
that
work
in
debt
net,
so
it's
possible
that
it
would
continue
what
you're
suggesting
here
is
breaking
off
the
wireless
part
into
a
new
group.
You
know,
I,
see
pluses
and
minuses
I
just
think
we
have
to
really
coordinate
in
there
in
order
to
make
that
work.
But
you
know
we
can
talk
to
each
other
and
we
do
so.
A
N
N
N
What
what
do
we
do
at
that
layer?
Basically,
we
standardize
control,
plane
and
measure
a
measure
and
plane
for
everything
that
is
known,
IP
that
sits
at
the
lower
layer.
So
we
deal
with
the
cross,
connects
switches,
Road,
arms
time,
division,
multiplexing,
Ethernet
switches
and
yes,
Wireless.
We,
we
have
recently
started
working
on
microwave
links,
so
there
could
be
synergies
with
what
what
is
being
discussed
in
this
in
this
environment.
N
Talking
about
to
the
work,
what
what
we
are
focusing
on
right
right
in
these
days
again
extensions
to
traffic
engineering
protocols
for
non
packet
technologies,
so
your
0
layer,
1
layer,
2,
it's
basically
what
you
probably
are.
The
under
the
name
of
gmpls
is
a
generalized
version
of
MPLS.
That
applies
to
all
non
pocket
technologies.
We
do
extensions
through
the
IGP
protocols.
Yes
is
SPF
signaling
protocols,
rsvp-te
on
the
undefined
by
other
working
groups.
We
honor
the
last
protocol.
Lmp
P
stands
for
link
management
protocol.
N
It's
a
protocol
that
is
used
for
several
purposes
like
maintain
a
control
channel
connectivity.
So
this
is
not
something
multi
operon,
and
this
is
a
specific
to
a
single
link.
It
is
used
to
verify
the
physical
connectivity
of
the
data
links,
correlate
the
link
property
and
the
suppressed
downstream
islands,
and
then
young
young.
N
A
O
On
this
slide
that
you
just
showed,
my
name
is
Charlie
Perkins.
You
showed
some
interesting
things
that
you
want
to
monitor
and
measure
about
links.
Do
you
think
that
your
tech
nature?
Do
you
think
they,
on
the
slide
that
you
showed
you
we're
making
measurements
for
various
properties
of
the
links?
Are
those
techniques
and
C
camp
applicable
to
wireless
links.
J
Actually
you're
going
through
here-
this
is
Lou
Berger,
sorry
you're
going
through
here
and
it
occurred
to
me.
I
left
something
off
the
men.
A
working
group
is
working
on
a
protocol
called
deal
up
and
I
actually
ended
up
doing
some
work
on
deal
app
because
I
worked
on
LMP
and
deal
up
is
LMP
for
wireless
networks
because
they
didn't
know
about
LMP
at
the
time.
Lal,
MP
and
I
think
this
is
Charlie's.
J
J
A
A
60-Ish
could
share
hat
on
so
a
toad
fitting
for
time.
Slotted
channel
hopping
provides
you
with
this
nice
metrics
of
time
and
frequency,
and
you
can
allocate
resources
a
given
square
there
being
the
time
just
to
send
a
packet
and
get
an
act
arrangement
back,
and
you
see
that
you
can
allocate
a
particular
of
those
resources
to
a
particular
transmission.
You
could
use
that
in
some
initial
protocols
use
that,
for
quote
encode
deterministic
properties.
What
we've
done
at
sixty
was
considered
the
other
side
of
that
net.
A
So
what
six
dish
has
done
so
far
and
what
it
was
attend
intending
to
do
was
to
enable
ipv6
on
the
slots
that
you
can
see
there,
that
the
deterministic
flows
would
not
be
using
how
to
be
elastic,
how
to
adapt
to
traffic,
which
is
non-deterministic
and
60s
has
been
doing
that,
and
we
are
very
close
to
completing
our
Charter
and
terminating
the
working
group.
What
six
dish
also
did
is
write.
A
Quote-Unquote
enough
were
not
cuttin
could
write
an
architecture
that
details
both
the
stochastic
traffic
in
the
deterministic
traffic
and
based
on
that
architecture,
promote
some
work.
At
that
net
I
mean
we
wrote
a
6-4
bet
net
or
that
natural
60
I,
don't
remember,
which
other
document
explaining
to
death
net
what
the
requirements
would
be
from
our
standpoint
to
enable
determinism
on
the
TSH
network.
But,
as
Lu
said
I
mean
and
as
Ethan
said,
the
wireless
is
not
the
first
priority
for
that.
A
Nets
though
we
we
wanted,
and
you
still
want
to
completely
inherit
the
debt
net
architecture
for
wireless.
We
also
needed
and
that's
what
to
express
there
to
be
able
to
configure
something
more
something,
maybe
more
complex,
something
different
which
would
be
the
the
wireless
network.
So
that's
why
we
are,
on
the
one
hand,
we've
got
with
enabled
classical
IP
stochastic
LP
on
a
deterministic
mark.
That's
the
ACH.
We
know
how
to
avoid
collisions
between
deterministic
and
non-deterministic,
but
60s
has
done
nothing
and
will
do
nothing
about
the
deterministic
side
of
it.
A
How
to
apply
that
net
on
that
TSH
network
and
that's
pretty
much
for
a
number
of
good
reasons.
One
of
them
is
wrong
area.
One
of
them
is
wrong
people
in
the
room.
We
we
wanted
to
do,
focus
from
jch
and
maybe
take
a
more
global
view
on
more
wireless
network.
Now
we've
got
an
architecture
that
works
on
TSH,
maybe
generalize
it
a
little
bit
and
inherit
from
both
the
TCH
architecture
around
the
dead
net
architecture
and
to
make
something
which
is
consistent
between
the
two
and
that's
pretty
much.
A
A
D
Yeah,
this
wonder,
understand
the
application,
the
workloads
you're
considering
here,
because
the
values
that
you
said
consider
has
audio
video
kind
of
applications
and
15.4.
What
I
understand
is
like
hundred
to
probably
300
or
400
kilo.
Bits
per
second
kind
of
mediums
is
I
mean.
Are
you
considering
high
bandwidth
applications
or
okay.
D
A
So
TCH
is
not
constrained
to
have
these
two
fully
functional
devices.
It
is
operating
on
a
15-4
network
with
any
kind
of
devices,
but
you
need
to
have
this
Matalin
extension
over
the
15
for
mac,
which
enables
to
understand
timing
so
to
synchronize
and
to
understand
schedules.
So
this
is
the
I
used
to
be
15
for
each
and
sixties
operates
on
that
now.
It's
all
wrapped
up
right
back
into
15
for
2015,
but
we
we
operate
on
that,
it's
obviously
a
constraint
network.
We
would
say
2
to
15
for
and
usually
very
slow
like
in.
D
A
For
robots
and
movement
detection,
I
mean
you
don't
do
that
with
TSH,
but
we
can
do
long-distance
and
that's
also
appreciate
t2
and
the
real
point
of
doing
LP
v6
about
that
was
to
enable
Diagnostics
all
the
backend
data
that
could
not
interfere
with
the
control
loops
and
that
shouldn't
still
need
to
be
carried
on
the
same
network.
Yeah.
C
A
J
A
No,
we
are
not
assuming
that
actually,
the
AFT
of
what
we
are
doing.
That's
not
really
does
not
centralize
the
allocation
of
channels
right.
So
it's
all
found
dynamically
by
screening,
the
air.
So
we
don't
assume
anything
we
just
look
at
for
time
slots
which
are
not
being
used
in
our
area
and
we
are
locate
them
for
peer-to-peer
communication.
That's
what
sixties
does,
but
six
Tish
is
not
some
truly
controlled.
It's
distributed.
A
P
A
J
A
Well,
we
expect
this
group
to
complete
the
dot
of
the
sixties
architecture.
The
sixties
architecture
describes
stochastic
and
deterministic
flows,
but
the
working
group
only
worked
on
stochastic
flows
and
expected
to
inherit
from
the
work
in
debt
net
for
the
deterministic
flows
and
as
we
think
about
that,
you
realize
that
probably
it's
better
to
dismount
six
Titian
from
a
new
working
group
for
doing
that
piece
as
opposed
to
Austin
1860s,
which
was
not
remand
for
it.
J
A
Probably
the
next
presentations.
Thank
you.
It
would
be
too
constrained
for
working
group,
probably
to
just
focus
on
one
technology.
Now
we
know
where
we
are
going
so.
The
goal
here
is
one
of
the
reasons
why
six
dish
is
not
appropriate.
Is
we
want
to
extend
to
more
radios,
and
so
with
this
we'll
start
with
the
first
of
those
radios
which
are
not
ACH
and
that
will
be
a
two
2.11
extremist,
robot
I
hope
we
have
Dave
here,
see
you
Dave.
Can
you
try
to
join
the
mythical.
L
A
A
L
Q
3Gpp
has
analyzed
various
use
cases,
for
example
smart
grid
or
mobile,
robots,
etc,
and
you
know
they
require
reliability
from
three
lines
to
five
nines
even
beyond
and
low
latency,
for
example,
boils
down
to
0.5,
millisecond
or
1
millisecond,
and
currently
LTV
do
not
have
this
capability,
for
example,
they
are
desired.
They
are
built
to
serve
traffic
with
the
blocker
rate
of
10%
or
mean
or
I
would
say
the
reliability
around
90%.
So
clearly
we
need
something
which
can
serve
with
extreme
reliability
and
low
latency.
Q
Therefore
we
began
working
with
the
GNU
radio,
which
is
called
N
or
5:03
release,
15
already
being
done,
and
and
now
we
are
working
with
Lee
60.
So
in
release
15
we
targeted
the
reliability
of
5/9
and
latency
0.5
millisecond
in
either
direction
of
which
is
from
wow.
You
can
say
RLC,
mac,
ingress
and
egress
points,
and
after
completion
in
18
we
are
working
in
you're
working
in
at
least
16
and
and
we
have
the
same
targets
and
we
increase
the
reliability
to
further
to
six
nines.
Q
So
in
this
slide,
I
have
some
low
latency
features.
I
will
just
go
through
some
few
of
them.
First
is
numerology,
and
here
from
from
legacy
one
millisecond
for
GTT
I
be
able
to
scale
the
TTI
duration.
This
transmission
time
interval
interval
time
slot
to
further
point
zero,
six
to
five
millisecond.
So
a
lot
of
latency
we
can
save
with
this
with
the
numerology
adoption
and
next
is
grant
free
in
the
grand
free.
Whenever
you
have,
data
transmitted
user
has
jet
advance
with
it
transmits
readily
on
the
pre-allocated
resource.
So
it
means
it
bypasses.
All.
Q
The
scheduling
require
signaling
related
to
scheduling
requests,
for
example,
in
uplink.
You
you
have
this
scheduling
request,
then
grant
then
buffer
status
report
then
further
actual
grant
where
the
transmission
happens.
So
so,
if
they
adopt
grant
feed,
so
we
can
bypass
all
this
for
signaling
and
user
transmit
readily
on
this
pre-allocate
resource.
Similarly,
we
can,
we
can
have
either
the
same
concept
in
the
in
the
downlink
is
more
easy
or
flexible
in
the
sense
G
not
be
or
what
the
base
station
controls.
The
transmission
uplink
is
bit
critical.
Q
As
we
know
in
new
release,
new
radio,
we
have
range
of
services,
so
that
means
the
traffic
can
be
critical
or
non-critical,
so
there's
an
interaction
between
these
mixed
services.
So
if
the
resource
is
allocated
to,
let's
say
non-critical
stories
and
and
we
have
to
serve
some
locator,
reliable
or
critical
service,
so
what
do
we
do
if
there
is
no
available
resource?
Q
So
we
can
interrupt
the
non-critical
service,
so
we
can
puncture
that
service
and
put
your
also
data,
which
is
a
critical
one
and
in
and
in
subsequently
there,
for
example,
in
the
downlink
we
can
send
the
indication.
Ok,
such-and-such
Services
has
been
interrupted
so
another
technique
and
it
also
saves
latency,
because
we
need
not
to
wait
for
the
free
up
resource
in
the
future.
We
just
do
it
really
fast
hard
processes.
Q
Q
Q
Then
we
have
infinite,
it
needs
we
have
more
bandwidth,
millimeter-wave
extra
and
then
further.
Let's
say
in
4G,
we
have
I
think
eight
votes
for
the
beamforming.
Now
we
have
to
also
up
gradation
from
those
techniques
automatic
repetition
we
can
use
repetition
in
downlink
and
uplink
for
the
reliability,
increases
the
success
probability
and
participate
duplication
in
this
layer.
This
is
above
our
LC
mac
or
LC
p
disappear,
and
in
this
layer
now
we
can
duplicate
the
packet.
So
it's
the
same
data,
but
even
it
may
carry
different
hot
processes.
Q
So
it's
sort
of
like
provides
reliability,
do
y'all,
say,
communication
and
support
for
time
system.
Networking
so
it
has
TSN
has
let's
say:
2
features,
tracking
features.
One
is
well
a
bad
atomistic
flow,
so
we
can
say
all
those
features
presented
in
these
slides,
low,
latency
or
high
ladee.
We
can
use
that
to
exploit
or
provide
the
deterministic
scheduling,
secondary's
accurate
time
delivery.
Q
Right
now
we
are
discussing
okay,
we
shouldn't
have
jitter
no
more
than
one
microsecond.
Oh,
you
know
the
clock.
Information
should
arrive
it
that
accuracy
in
3gpp
different
angles,
working
on
different
problem
related
to
the
clock
accuracy.
For
example,
in
my
group
plan
one
we
are
analyzing
the
clock
accuracy
over
there
or
over
the
you
you
interface
between
you,
Eng
node
B.
So
we
can
say
that,
for
for
a
cell
site
of
less
than
10
meter,
we
can
provide
accuracy
of
from
something
less
than
500
or
400
nano.
Q
F
Q
Q
So
as
I
discuss
in
uplink,
we
have
a
grand
frame
so
due
to
gran
free
there's,
a
concept
adopted
in
uplink
is
configured
grant.
So
in
the
configured
grant,
we
say
in
the
uplink
that
we
can
pre
allocate
the
resources,
and
whenever
user
has
a
data,
it
can
transmit
readily
in
a
grant
free
manner.
First,
for
example
a
in
this
in
this
figure
in
the
uplink
case.
So
you
have
a
period
here
which
can
be
emulated
to
the
latency
budget.
So
in
that
latency
budget,
here
we
allocated
for
transmission
opportunities.
Q
So
whenever
our
user
has
a
data
to
transmit,
for
example,
it
can
transmit
on
this
for
transmission
opportunity
by
for
transmission
opportunities,
meanings
for
repetition
for
reliability.
So
in
this
way,
user
can
have
a
reliable
uplink
transmission
for
the
critical
data,
and
these
transmission
can
go.
Repetition
can
go
up
to
16
depending
on
how
critical
is
your
traffic
further?
We
have
a
multiple
configured
grants
and
and
if
your
traffic
is
a
bit
fluctuating,
so
you
can
adopt.
You
know
one
of
the
configured
grant.
Q
Q
Adding
the
more
reliability
next
is
downlink.
Okay,
APNIC
is,
as
I
said,
more
critical,
so
you
know,
because
user
has
to
do
a
lot
of
ok,
so
I
will
just
do
fasts.
Okay
in
the
downlink.
We
have
this
SPS.
So
this
is
these
are
on
the
table.
We
can
reduce
the
period
and
further.
We
can
have
multiple
SPS
again
for
that
office
scheduling.
Q
So
this
is
some
way
we
are
done
with
release
15.
Now
we
are
working
on.
Only
16
study
items
are
finished.
We
have
some
focus
problem
in
a
sixty
and
deterministic
scheduling.
Update
configured
turned
can
be
considered
as
a
baseline
enough.
Okay
and
similarly,
we
have
it
downing
multiple
SPS
old
down
in
casapierce
testing
capabilities.
We
are
analyzing,
both
deterministic
flow,
as
well
as
the
clock,
accurate
clock
information
to
live
free.
Thank
you.
Thank.
A
Because
we
are
getting
late,
but
thanks
so
much
as
we
appreciate
it
and
we
see
that
they
didn't.
You
know
we
see
where
we
should
be
already
on
this
picture,
where
you
see
that
yes
and
is
talking
to
all
three
without
going
through
that
net
and
that's
kind
of
oh
it's
time
to
look
at
that
well
to
see.
If
we
can
do
something
at
layer,
3
to
generalize
this
interconnection
of
n22
monistic
flows,
the
Queen,
that's
not
sure
it's
gonna
be
Dave.
First
Pascal.
J
J
But
if
we're
looking
at
a
sort
of
a
multi
network,
we
may
say
that
the
best
way
across
multiple
hops,
so
not
across
a
single
subnet
but
across
the
n
subnets
that
we
really
need
to
introduce
something,
that's
different
than
the
simple
one,
plus
one
and
and
really
look
at
network
coding,
and
so
that
might
be
something
for
a
future
group
that
we
could
look
at
here.
Okay,.
L
A
K
A
R
R
R
Next,
it
is
okay,
I
didn't
saw
it
sorry,
so
the
global
traffic
in
the
air
becomes
more
and
more
complex,
and
the
problem
is
that
the
base
stations
want
to
have
control
over
all
communications
happened
between
the
planes,
as
well
as
the
ground
stations,
and
also
manage
the
air
traffic
in
all
phases
of
the
flight.
So
currently
there
are
many
developments
on
going
to
modernize
the
air
traffic
management
for
civil
aviation
and
transitions
from
analog
to
digital
communications.
R
R
The
idea
is
that
it's
a
report
already
indicated
that
there
will
be
more
and
more
traffic
in
the
air
and
the
currently
available
bandwidth
with
the
communication
between
the
different
planes
in
the
frequency
band
are
already
very
full,
so
they
are
looking
for
new
frequencies
or
bands
to
communicate
the
air,
and
also
the
data
is,
is
not
only
with
the
data.
That's
communicating
like
the
local
position,
but
also
coming
up
more
and
more
requests
for
videos,
for
example
to
analyze,
for
example,
weather
conditions.
Next
slide,
please.
R
So
in
this,
the
El
Docs
solution
comes
in
standing
for
help
and
digital
aeronautic
communication
systems
and
air
ducts
will
provide
a
solution
that
goes
on
all
communication
way,
so
between
the
different
planes
between
different
and
planes
and
the
satellite,
as
well
as
ground
stations
and
within
the
airport
surroundings.
Next
slide,
please.
R
The
here
is
a
basic
architecture
described
on
the
slide,
so
you
can
see
that
we
have
different
communications
on
the.
On
the
one
hand,
when
the
plane
comes
in,
we
need
to
have
information
to
the
ground
station
at
the
airport,
as
well
as
when
the
plane
leaves.
We
have
to
do
the
communication
way
backwards,
as
well
as
the
different
planes
have
to
communicate
with
each
other
and
there
they
are
using
ground
station,
where
the
information
is
then
sent
to
a
central
point
to
a
controller
which
then
the
forwards,
the
different
communication
to
the
airport
spaces.
R
So
to
say,
and
from
there
the
communication
is
further
handled.
What
details
on
this
are
already
published.
So
at
the
end
of
the
presentation,
you
can
see
a
whole
list
of
publications
going
on
that
topic
already.
So
I
save
some
time
here.
Next
slide,
please,
the
the
main
characteristics
of
El
Docs
can
be
seen
here
summarized
in
the
slide,
so
the
total
airspace
is
separated
in
different
cells.
R
So
at
the
end
the
final
information
goes
to
the
ground
station,
so
we
have,
on
the
one
hand,
a
rudiment,
a
basic,
centralized
communication
in
place
when
we
just
look
on
the
ground
station,
but
as
the
planes
are
mobile,
we
also
have
to
look
on
a
decentralized
approach,
so
the
idea
of
alex
is
to
combine
power
schemes
next
slide.
Please
and
combining
both
schemes
is
challenging
because,
as
we
all
know
also
due
to
the
5g
auction
at
the
moment
they
are
already
reserved
bandwidth
and
frequency.
R
R
Next
slide.
Please-
and
this
just
came
in
yesterday,
so
they
successfully
launched
the
prototype
L
Docs
and
did
the
first
flight
successfully.
So,
as
you
can
see,
I'm
not
ripped
not
talking
about
theory.
We
already
have
it
deployed
and
now
we're
looking
for
standardization
here
and
next
slide,
please
summer
in
L
Docs,
it's
important
for
poor,
because
we
are
looking
on
another
use
case.
Looking
at
the
aerospace
and
as
you
know
there,
we
have
different
settings
for
the
communication
compared
to
the
other
introduced.
You
use
cases.
R
So
we
also
have
to
think
about
secure
communication,
because
it
makes
no
sense
that
the
data
is
transported
but
might
be
eavesdropped
or
something
else.
So
it's
really
high
risk.
If
data
is
malicious
here
and
the
other
thing
is,
we
need
to
have
the
regulatory
organs
on
board,
because
the
DLR
got
the
contract
from
the
NATO
to
have
it
globally
acceptable
and
finally,
I
must
say
as
I'm
running
out
of
time-
and
we
are
already
behind
schedule.
R
R
T
Thanks
invitation
to
join
the
this
group,
so
I'll
give
an
update
on
the
support
from
time-sensitive
applications
in
age
11.
You
can
go
to
the
next
slide,
so,
as
everyone
knows
right,
additionally,
Wi-Fi
has
been
focusing
on
increasing
throughput
capacity
and
efficiency,
but
more
recently,
a
lot
of
the
new
applications
are
requiring
more
dangerous
high
throughput.
You
know
in
terms
of
a
low
latency,
high,
reliability
and
time
synchronization,
and
this
has
been
recognized
within
day.
T
2.11
group
and
some
work
has
already
been
done
and
more
work
is
is
ongoing
in
enabling
these
applications
you
know
within
a
2.11.
I
will
talk
about
two
main
efforts:
there
one
is
a
11a
X
which
provides
mechanisms
to
control,
latency
and
increase
reliability
and
the
new
next
generation
Wi-Fi
standard,
which
will
be
called
11,
B
or
extremely
high
throughput,
which
will
come
after
11
ax
with
just
starting.
You
know,
can
you
go
to
the
next
one?
T
Please
so
a11
ax
bring
the
new
capability
to
wait,
o
2.11,
which
is
a
multi-user
OFDM
a
so
one
of
the
main
issues
with
the
Wi-Fi
Mac
right,
as
you
know,
based
on
CSMA
is
a
contention
right
and
most
of
the
time,
the
delay
actually
is
very
low
on
average.
But
the
problem
is
in
the
worst
case
in
case
of
congestion.
T
You
can
schedule
multiple
users
at
the
same
time
and
you
can
avoid
or
you
know
they
D
see
a
contention,
and
there
are
other
other
features.
Also
that
enables
the
veto
to
allocate
the
barrier
resource
unit
and
and
agree
with
different
stations
on
times
that
they
can
be
active
or
not.
That's
something
called
TWT
so
combine.
These
features
gives
a
more
centralized
scheduling
capability
to
Wi-Fi,
which
can
avoid
a
lot
of
the
the
random
access
delays,
right
and
I.
Think
in
a
managing
environment.
T
This
can
already
be
used
to
to
support
low
latency
with
high
reliability
in
the
next
slides.
We
show
an
example
if
you
go
to
the
next
one
Basco
okay,
so
this
is
a
very
simple
example
to
show
the
difference
and
what
FDMA
can
help.
So,
if
you
have,
for
example,
nine
users
and
you
have
two
to
transmit
all
of
them
in
time
domain
right,
they
all
have
to
contain
for
access
it's
gonna.
Take
you
know
a
certain
amount
of
time.
T
If
you
have
each
one
of
them
it's
gonna
have
to
contain,
but
with
OFDM
a
you
can
actually
pack
all
of
them
in
a
single
PPD
you
and,
and
of
course
the
number
of
users
you
can
support,
depends
on
the
channel
available,
but
in
Wi-Fi
you
can
go
from
20
megahertz.
All
the
way
up
to
160
megahertz,
so
Yoka
pastic
and
you
know,
can
be
adjusted
as
well,
but
the
amount
of
time
required
is
significantly
less
in
terms
of
seven
hundred
microseconds
for
nine
users
compared
to
one
point:
three
milliseconds.
T
If
you
have
to
do
it
in
the
say,
legacy
Wi-Fi
way.
So
that's
one
of
the
the
capability
that
we
believe
is
very
important
for
these
low
latency
applications.
But
there
are
improvements
that
can
be
done
here
in
order
to
reduce
the
latency
even
including
increased
reliability
redundancy,
and
this
is
actually
starting
already
in
dot
eleven
with
the
work
in
the
new
group.
The
next
slide,
please
so
in
in
the
March
meeting,
the
working
group
approved
a
new
project.
It's
gonna
be
called
Task,
Group
B
and
they
will
study.
T
Group
was
called
EHT,
extreme
height
reports,
and
there
was
a
sub
group
that
focused
on
the
was
a
RTA
interest
group
that
Fox
only
on
looking
at
the
real-time
mail
time-sensitive
applications
as
I
list.
Some
of
them
here
I
think
some
of
those
were
discussed
previously
today.
So
I
won't
go
into
the
details,
but
this
group
looked
into
documented.
T
Different
applications
have
different
latency
or
reliability
requirements,
but
one
of
the
fundamental
problems
that
needs
to
be
addressed
in
the
dot
eleven
is
they
need
to
to
bound
the
latency
basically
to
address
the
worst
case,
latency
and
jitter,
and
this
has
been
included
now
in
the
scope
of
the
next
generation,
which
is
the
11b
project
and
the
next
one.
So,
and
these
are
some
of
the
topics
that
are
started
to
be
discussed
already
and
considered
in
the
in
the
neo
11b
first
one
is
extension
for
of
DSN
capabilities,
actually
in
dot
11.
T
There
is
already
support
for
some
DSN
capable
is
right.
There
is
support
for
time.
Synchronization,
as
was
discussed
early,
for
example.
5G
is
trying
to
enable
that
so
this
something
that
in
dot
11
it's
already
standardized
and
available
also
dot
11,
is
a
is
actually
a
802
network.
So
the
interface
with
ethernet
DSN
is,
is
natural
is
already
there.
T
So
there
are
amendments
like
that
11,
a
k'
that
enables
that
in
the
past
already
what
the
group
is
focusing
now
are
on
the
features
to
to
address
the
latest
in
the
reliability
of
the
links,
and
there
will
be
some
enhancements
for
more
predictable,
medium
access,
reduction
of
Phi
overhead
for
especially
for
small
packets
and
management
of
time
sensitive
and
the
best
effort,
coexistence
and
across
multiple
IPS
and
multiple
BSS.
So
those
are
the
topics
that
are
being
now
considering
the
next-generation,
11b
and
yeah.
So
this
is
a
short
summary.
T
If
you
are
interest,
we
can
fluently,
follow
up
in
with
details
and
what
results
you
know
have
been
already
discussed.
But
the
main
message
here
is
with
11
ax
they're
already
capable
is
that
you
can
control
the
latency,
especially
if
you
are
in
a
managed
network,
like
an
industrial
network,
for
example,
and
11
B
is
gonna
improve,
not
just
the
the
true
put,
but
also
reduce
the
the
worst
case,
latency
and
jitter,
and
have
improved
reliability
over
eleven
axo.
It
is
gonna
take
even
further
and
in
this
work
has
started
in
nitric
away.
A
U
A
U
I
will
focus
on
the
aspects
that
has
not
been
addressed
by
the
draft
published
or
presented
at
60,
but
some
of
the
topics
that
are
described
in
the
architecture
so
next
slide.
Please.
The
presentation
I
will
give
this
overview.
I
will
talk
about
the
concept
that
is
level
switching
on
60
and
is
something
that
we
already
talked
during
today
this
in
this
workgroup
in
this
both
presentations.
U
We
also
talked
about
what
are
the
tracks
according
to
the
16
architecture?
Next
slide.
So,
as
some
of
you
may
know,
time,
synchronized
channel
hopping
is,
is
an
amendment
of
15
for
that
was
presented
in
2012
and
then
standardized
in
2015,
and
what
provides
is
a
schedule
where
we
can
allocate
resources
for
the
communication
between
nodes
in
a
mesh
network.
U
So,
as
lot
is
one
of
these
cells
and
inside
the
slot,
there's
different
things
that
happened,
but
one
of
them
is
that
each
packet
is
acknowledged.
This
means
that
the
the
inner
mac
layer
properties
provide
this
reliability,
at
least
for
the
confirmation
of
the
packets.
There
are
other
options
provided
also
by
15-4
that
enable
retransmissions,
so
this
I
do
that
is
described
in
the
60
is
possible
thanks
to
the
already
defined
properties
of
this
Mackley.
The
next
slide,
so
60
took
that
Mac
layer
and.
U
U
So
I
think
it's
a
well-known
thing,
with
determind
sequence
of
cells,
along
with
the
hop
path
and
it's
usually
as
a
result
of
reservation
conducted
by
by
a
protocol
such
as
a
label,
distribution,
protocol
or
RSVP
like
protocol.
So
usually
these
trucks
can
can
have
an
owner
which
is
the
initiator
and
it
can
be
uplink
or
downlink
and
they
can
be
identified
in
many
ways
and
from
here
we
can
start
playing
a
lot
of
tricks
in
the
network
to
ensure,
for
example,
that
we
have
redundancy
on
the
on
the
tracks.
U
So
we
can
add
extra
levels
of
reliability
into
the
network
and,
as
a
final
slide,
this
is
judgment
an
illustration
of
what
we
understand
in
64
truck,
switching
or
label
switching
over
1540
seh,
which
is
basically
forward
the
six
top
layer,
which
is
the
management
layer
and
over
th,
designed
by
60
all
the
packets.
That
arrive
into
a
note
and
are
not
for
that
note-
and
this
of
course
avoids
a
lot
of
overhead
on
the
processing
of
the
packets,
because
we
are
acting
layer,
2
forwarders,
as
in
MPLS
and
I.
Think
that's
my
introduction.
A
Thank
you
very
much
Jerry,
just
as
a
60s
chair,
just
to
be
very
specific.
We
defined
all
these
as
at
the
architecture
level,
so
this
I
kind
of
our
requirements,
but
we
never
as
well
implemented
any
of
the
protocols
that
would
be
needed
to
achieve
this
and
that's
when
we
actually
went
to
death
net
and
said
how
can
we
work
together
on
making
that
happen,
and
that's
why
we
are
in
this
from
now?
Thank
you
very
much
Jerry
and
the
next
winner
is
about
40
ssin.
That's
going
to
be
me.
J
J
A
No,
it's
a
use
case,
oh
not
to
use
case.
It's
it's
one
of
the
radios.
The
interesting
thing
with
six
dish
is
that
it
is
already
considering
multi-hop,
which
the
others
did
not
present
to
you.
They
are
haven't
spoke
so
for
six
dish.
We
might
want
to
provide
not
just
one
hub
but
multi-hop
scheduling
so.
A
Six
cache
is
one
of
the
users
of
what
we
are
building-
okay,
but
but
it
compared
to
the
others.
It's
the
only
one
which
presents
it
as
a
mesh
problem,
so
multi
hub,
but
otherwise
you
still
have
the
same
FDMA
TDMA
kind
of
structure,
with
many
things
in
common,
and
so
actually
it
continued
on
the
discussion
and
I
will
go
to
the
mic
here.
A
A
What
can
we
use
that
net
as
it's
already
stands,
and
what
needs
to
be
extended
to
what
that
net
already
describes
in
its
architecture
so
as
to
solve
the
kind
of
frames
that
Chevy
has
just
presented
so
just
to
reuse
the
same
design,
a
traditional
forwarding
operation
would
be
you
get
to
know
the
envy
that
sends
same
packet
to
not
X
at
different
times
on
different
channels
and
then
on
different
time.
Different
channels,
X
would
forward
them
to
Y
and
then
Y
would
forward
to
U
and
V.
A
But
this
model,
which
is
the
traditional
folding
model,
is
not
necessarily
the
way
radio
networks
will
operate
for
us.
So
the
first
thing
that
may
happen
on
the
radio
network
would
be
the
traditional
quote:
unquote
and
that's
the
inheritance
from
that
replication
game.
So
we
would
have
one
time
slot
channel
offset
frequency
offset
on
which
this
node
G
would
receive
a
packet
from
ingress
I,
and
we
see
that
we
can
schedule
to
two
times
to
frequency
and
time
where
G
would
actually
forward
to
a
and
F
right.
A
One
thing
we
didn't
say
about
ACH
is
we
are
not
using
this
us
as
fixed
channels.
We
are
rotating
that
all
the
time,
so
we
have
a
channel
and
frequency
diversity
because
we
recompute
what
you
see
in
this
matrix
into
a
real
frequency
based
on
time.
So
it's
not
directly
frequencies.
Don't
think
like
that.
A
Now
now
we
get
into
more
unusual
operations.
One
of
them
is
a
very
hearing
and
we'll
have
John
just
talk
about
that
a
little
bit
later,
but
there
is
one
interesting
aspect
of
the
radio.
In
the
one
hand,
it's
lossy
right,
you
don't
have
the
same
kind
of
deliver
ratios
most
in
DSM
mailed
in
unlicensed,
but
on
the
other
hand,
you've
got
interesting
properties
like
it's
often
used
as
a
broadcast
medium.
A
Unless
you
do
tight
beamforming,
you
have
a
good
chance
that
that
will
be
more
than
one
device
on
your
mesh
that
can
it's
capable
of
receiving
a
packet
when
it's
being
emitted.
So
the
first
operation
that
we
might
won't
have
to
program
schedule
into
our
network
is
this
veneering
mechanism
whereby
G
sounds
the
forget
broadcast
since
in
the
air
and
actually
F
and
H
are
both
programmed
to
capture
that
packet.
A
Another
game
which
is
harder
to
do
with
our
papers,
which
do
that
and
seen
data
so
in
the
plans
for
5g
so
become,
might
but
tell
us
about
that,
but
a
constructive
interference.
It's
the
way
to
say,
I'm
very
tightly,
synchronised
packets
from
two
different
sources,
so
that
the
way
those
two
transmission
interfere,
the
receiver
are
actually
constructive,
meaning
that
the
receiver
will
get
more
energy,
and
so
it
can
receive
the
packets
ability
if
it's
further,
along
and
and
too
far
to
be
reached
by
any
individual
I.
A
Oh
that's
a
good
way
to
work
at
the
border
of
two
cells.
If
you
like,
something
which
is
very
very
used
used
in
various
usual
on
wireless,
but
completely
unusual
on
wires
is
playing
a
RQ.
That's
the
you
know,
retry
request
in
that
game.
We
would
basically
use
of
the
same
I
and
the
same
J,
but
I
would
send
the
packet
to
J,
and
if
it
gets
an
acknowledgment,
then
it
will
not
need
to
resend
the
packet,
but
if
it
doesn't
get
an
acknowledgment
and
it
will
resend
the
packet.
A
The
controller
has
to
be
aware
of
this
AR
q
capability
and
the
Meraz
ratio
on
the
particular
hub
so
as
to
program
enough
time
slots
to
get
the
kind
of
reliability
we're
after
in
the
terms
of
sixty
shark-attack
shell.
There
is
a
logical
relation
between
those
two
time
slots,
it's
an
or
with
logical
representation,
and
that's
basically,
my
summary
for
or
what
six
dash
would
basically
ask
from
from
power,
basically
use
all
the
forms
of
diversity
is
to
improve
the
delivery
so
with
within
the
schedule,
time
and
I'm
listing
here.
A
Some
form
of
diversity
is
that
can
be
used
for
TSE
h,
but
also
for
other
radios,
and
so
you
get
your
special
diversity.
You
can
build
a
track
which
is
getting
complex
with
multiple
paths
and
synchronization
points,
etc.
So
the
track
is
not
a
serial
list
of
nodes
anymore.
It's
a
very
complex
thing,
like
a
ladder
or
even
multi-level
ladder,
beam
forming
an
open,
different
beams
to
use
different
reflections.
That's
that's
again
that
can
be
played
tender
st
with
rich,
wise
and
time-division
frequency.
A
At
the
same
time
as
we
want
to
use
all
that,
we
don't
want
to
spend
all
the
energy
that
would
be
necessary
to
exploit
all
the
possible
hubs
and
all
the
possible
beams
etc.
So
we
want
also
to
observe
the
quality
of
the
links,
use
the
best
ones
and
not
waste
energy
and
interfere
by
using
the
wrong
ones.
That's
when
you
know
that
is
all
this
need
an
OEM
that
I
discussed
earlier.
A
B
B
A
That
was,
that
was
an
idea
right
initially
I
mean
for
like
two
years.
We
thought
a
let's
push
these
requirements
and
we
have
the
64
debt
net
draft,
which
has
been
hanging
out
for
like
two
years,
and
we
basically
expected
some
protocols
to
come
on
out
of
definite
that
of
that
net,
which
we
could
kind
of
adoptions
to
or
something
to
do,
the
sixties,
games
and
well
for
the
one
thing:
it's
not
work,
which
is
I
priority
for
that
net.
To
be
clear,
the
wireless
options
would
I
was
discussing
in
working
groups.
A
Second,
is
six
dishes
in
the
interior
and
on
the
crowd
that
was
working
on
six
dish
was
an
ipv6
over
full
crowd.
So
for
this
game
we
want
more
TCK
up
that
net
kind
of
crowed
intermixed
with
with
radio
people.
So
it
seems
that
we
need
to
change
crowd.
We
need
to
dwell
renew
a
bit
our
crowd.
We
need
to
maybe
change
area
so
there,
and
also,
as
we
do
that,
and
we
work
a
lot
and
reusing
work
which
is
done
by
sea
camp,
that
night
etc.
A
It
appears
that
focusing
on
a
single
radio,
like
was
the
charter
of
sixty,
you
know,
is
no
more
right
idea.
We
need
to
abstract
that
a
little
bit,
sixth,
is
being
one
of
those
things
we
work
for,
and
so
all
these
reasons
together
tell
me
that
you
know
trying
to
to
extend
60s
right
six
dish.
All
that
way
is
probably
not
as
good
as
just
you
know,
forming
a
new
group
and
and
saying
okay.
A
V
V
So
the
actual
way
in
which
the
problem
gets
solved
is
like
still
open
to
interpretation,
is
just
gonna,
be
sitting
in
some
current
working
group,
I
said
gonna,
be
even
a
working
group
or
a
new
working
group
like
that
all
needs
to
be
decided
like
in
the
future
and
I
specifically,
don't
want
to
spend
time
on
it
like
for
today.
I.
My
goal
is
to
really
understand:
is
there
a
problem
to
be
solved
and
is
there
interest
right
like
and
then
we
actually
look
at
the
actual
dynamics?
So
this
could
be
like
you
know.
V
Lou
I
want
to
make
you
jump
like
it
could
be
done
in
debt
net,
for
example,
some
part
of
the
work
and
like
we
could
start
parceling
this
out
to
like
multiple
groups
right.
So
that's
something
that
we
can
discuss
afterwards,
like
not
really
right
now.
So
my
goal
is
just
figure
out:
is
there
something
that
needs
to
get
done
in
the
ITF?
Go
ahead.
J
Wasn't
here
originally
for
me,
but
I'll
just
said,
doesn't
want
me
to
jump
up
all
sets
I'm
here,
I'd
actually
say
the
six
dish
problem,
particularly
if
you
want
distributed
signaling
belong
squarely
in
sea
camp.
That
they've
done
that
whole
lot.
So
C
camp
would
be
the
right
place,
so
not
that
this
is
now
for
Mena
Rati
I'm
curious
for
your
thoughts
on
the
feasibility
of
such
organization
in
a
distributed,
hop-by-hop
manner.
So
I
guess
it
sits
on
the
previous
one
about.
J
A
C
My
name
is
George
for
me
and
that
Lanting,
France
and
I
will
present
you.
The
requirements
of
the
packet,
replication,
elimination,
but
earlier
presented
so
I
will
skip
some
of
my
slides
because
I'm
trying
to
say
the
same
thing.
So
we
have
the
the
wireless
topology
is
the
source
D's
in
this
nation,
again
B
or
the
relay
devices,
and
then
under
such
Wireless
topology.
The
replication
will
be
when
a
strands
meets
the
data
packet
is
to
a
to
its
pollen,
and
then
he
will
replicate
to
its
alternative
parent
to
B.
C
So
this
is
the
replication
and
because
we
have
too
much
duplication
and
unnecessary
traffic,
we
will
need
to
use
what's
called
elimination
to
discard
the
copies
of
the
previously
received
data
packet.
So
is
the
elimination
I
will
go
first
of
with
overhearing
as
well.
So
actually,
the
idea
here
is
when
ace
as
a
source
transmits
to
its
parent
because
of
things
to
the
raddest
medium,
which
is
broadcast
by
nature.
C
We
may
have
this
permissible
hearing
and
being
way
over
here
to
visit
transmission
and
like
this
will
be
managed
to
increase
the
reliability
in
the
network,
and
this
is
the
simple
example
of
the
TSH
schedule
that
we
may
have
when
we
were
using
this
topology,
where
s,
transmits
to
a
and
B
in
parentheses,
will
be
the
overhearing
device.
I
will
skip
this
and
we
go
to
the
straight
to
the
requirements.
C
So
actually,
when
we
won't
apply
theory
in
the
wireless
network
like
TCH
and
report,
the
routing
layer,
we
are
having
some
requirements
to
consider
eight,
and
one
of
them
is
related
to
the
pattern
selection.
So
when
we
want
to
find
the
alternative
parent,
we
should
define
what
kind
of
what
kind
of
topology
we
are
going
to
work.
We
may
need
to
know
whether
we
are
having
or
not
another,
so
many
parallel
paths
was
the
density
and
so
on.
C
This
is
something
that
we
need
to
consider
before
then
related
to
the
routing
protocol,
which
it
should
allow
for
each
device
to
have,
in
addition
to
its
default,
or
the
default
party,
what's
called
to
have
a
second
one
and
alternative
parent.
So
we
will
manage
to
make
this
replication
function
and
then
the
third
requirement
for
the
alternative
pattern
selection
will
be
to
if
we
want
to
control
the
flooding
we
need
to
carefully
select
the
alternative,
parent
and
here
I
have
a
small
example
between
the
disjoint
paths
and
the
common
ancestor.
C
So
in
this
example,
if
we
are
not
careful,
selecting
the
alternative
parent,
we
may
end
up
what
we
see
here
on
the
right
figure
with
this
joint,
so
we
are
having
uncontrolled
flooding
right
services,
unnecessary
traffic,
energy
consumption
and
so
on.
While
we
are
somehow
controlling
this
pollen
selection,
we
may
have
this
bottle
what
we
call
common
ancestor,
where
we
will
have
two
parallel
paths
that
goes
from
the
source
to
the
destination.
So
here
we
somehow
control
the
flooding.
C
Sorry
two
examples,
then:
if
we
consider
consider
to
go
for
the
common
ancestor
pattern,
then
we
may
need
to
have
some
extra
information
so
that
we
select
this
alternative
parent
properly.
So
to
do
so,
if
we
are
working
with
ripple
in
60s,
then
we
have
to
extend
the
control
packet
in
this
case
is
the
DAO
as
an
example.
C
Then
the
third
requirement,
related
with
to
the
permutation
will
hearing,
will
be
that
remote
computation
will
support
bypassing
the
MAC
address
filtering
to
accept
the
overhead
frame
so
meaning
that
in
this
example,
when
S
will
transmit
to
its
parent
a
remotely,
we
should
allow
that
the
be
device
should
accept
should
receive
this
budget
by
overhearing
it
and
then
the
fourth
requirement.
It
is
related
to
the
packet
elimination.
So
when
we
do
all
this
application
at
certain
point
it
device,
we
receive
multiple
copies
of
the
same
data
packet
and
we
need
to
do
this
elimination.
C
C
So
here
we
have
different
parents
selection
mode.
So
let's
say
this
is
the
common
ancestor,
meaning
that
to
select
alternative
parent
is
the
one
having
common
ancestor
with
a
different
parent,
so
the
preferred
parent.
So
here
we
have
three
different
modes
from
the
strict
or
soft
root
and
the
more
from
the
strict
from
the
software
step.
We
go
the
lower
the
probability
to
find
this
alternative
torrent
and
most
of
the
days
we
are
having
higher
chances
and
which
we
reflect
to
our
results.
C
We
have
here
based
on
this
topology
in
these
configurations,
so
the
PBR
here
you
will
see
that
we
managed
to
have
with
packet
application
elimination,
similar
results
in
terms
of
the
PDO.
We
think
the
same
slot
frame
when
I
say
within
the
same
slot
frame.
This
reflects
to
this
nice
figure,
which
is
a
delay
in
the
jitter.
Basically,
if
you
can
see
all
three
columns
on
the
left
so
stick
see
a
medium
and
soft
all
of
them.
C
They
are
having
this
bounded
delay
and
if
you
see
more
carefully,
we
have
the
digital,
which
is
super
super
super
low.
So
it's
here,
so
this
is
because
when
you
manage
to
have
correctly
to
the
delay,
so
we
have
nine
stator,
which
you
can
see
in
the
next
figure
in
the
top
right
without
seat.
And
then
this
is
the
next
video
that
shows
that
there's
a
cost
to
pay
and
the
cost
is
that
we
have
to
traverse
the
packet
through
more
devices
and
we
traverse
through
the
more
devices
in
this
multi-hop
wireless
network.
C
A
A
A
Is
an
onsen
thing
which
is
part
of
the
discussion
that
we
had
with
the
ASG
to
to
enable
this
birth
today?
Was
that
power
useful
as
it
is,
is
not
a
good
idea
for
an
ATF
working
group.
If
ever
we
form
one,
because
it's
too
close
to
powers,
which
was
something
in
white
space
and
I,
swear
she's
coming
and
so
will
give
you
the
ball,
no
go.
A
Okay,
so
basically
the
idea
is
whatever
we
do
from
now.
After
our
discussion
on
the
mailing
list
would
not
be
called
power
anymore
odds,
gonna
be
called
spawn,
so
we
actually
spawn
this
working
group
from
that
net.
C
camp
I
mean
three
about
narrating
work
from
everywhere
and
extending
it
to
our
radios,
and
so
that
would
be
adding
schedule
in
front
of
power
and
networking
in
the
end
and
now
that
the
races
after
logo.
So
if
you
have
any
idea
for
a
good
logo
for
spam,
then
was
interested
and
Suresh.
Whatever
points
yours,
okay,.
V
So
personally,
Pascal
by
I
found
like
two
things
like
off
interest.
Sure
that's
work
to
do
so.
Tell
me
if
I'm
off,
okay,
one
of
them
is
like
really
like
me,
om
work
so,
like
you
know,
doing
the
packet
loss
eval
and
like
something
that
balances
the
resiliency
versus
like
energy
usage.
That's
one
thing
and
the
other
thing
is
some
kind
of
signaling
to
do
the
poor
flow,
like
with
specific
you
know,
special
time
and
frequency
constraints.
So
those
are
the
two
pieces
of
work.
V
I
saw
pretty
much
and
and
we
really
need
to
sit
down
and
figure
out
like
you
know
how
this
gets
done
right.
So
it
should
this,
be
a
separate
working
group
on
art.
So
I
understood
your
argument
like
why
it
should
be
a
working
group
but
I
think
that's
something
we
still
need
to
discuss.
Or
can
it
just
parcel
off
the
work
and
do
some
kind
of
loose
coordination?
That's
another
possibility.
So
that's
something
we
need
to
evaluate
later.
V
I
thought
you
would
have
some
time
at
the
end
of
this
meeting
to
do
that,
but
you're
out
of
time
to
do
that
and
I
think
we
should
continue
discussing
that
before
we
lead
up
to
Montreal,
so
we
need
something
a
little
bit
more
specific
and
probably
a
little
bit
more
socialized
with
the
debt
Ned.
You
know
the
tease,
folks
and
stuff
like
that
right
and
so
I
think,
like
you
really
had
a
good
point
when
he
talked
about
like
you
know,
there's
some
stuff
that
has
like
really
homes
in
routing
right.
V
So
that's
something
you
have
to
figure
out,
probably
offline
to
see.
Is
there
a
working
group
needed
or
not?
And
and
that's
something
we
have
quite
a
bit
of
time
to
do
that
and
that's
something
I
want
to
focus
on
just
to
make
sure
that
everybody
understands
the
deliverables
and
see
where
they
can
be
done.
A
Okay,
so
many
thanks
I
guess
it's
we
have
past
time,
so
it
will
be
time
to
add
John
I.
Thank
you
all
for
coming
and
the
remote
presenters
for
presenting
to
us
I
think
that
was
great
in
tradition
to
a
number
of
those
radio
technologies
and
for
some
of
us
an
interesting
also
view
that
we're
less
can
be
kind
of
transient
some
days.
So,
let's
discuss
more
on
the
mailing
list.
It
will
spawn
will
be
created
very
soon.