►
From YouTube: 20220317 International Standards and M17
Description
Welcome to Practical Open Source Engineering: International Standardization and the M17 Protocol. My name is Michelle Thompson and I'm your host for today. Thank you for being here.
Practical Open Source Engineering is a series of talks from the San Diego Chapter of Information Theory Society of the Institute of Electrical and Electronics Engineers, or IEEE for short. IEEE is the world's largest professional engineering society.
Open Research Institute, a non-profit dedicated to open source research and development of digital radio in all aspects, is the co-sponsor of the Practical Open Source Engineering series and is the fiscal sponsor of the M17 Project. To learn more about ORI's work, please visit openresearch.institute on the web.
M17 project development is the subject of today's talk. To find out more about M17, please visit m17project.org
Technologies do not grow and mature in isolation. To maximize utilization, organizations often turn to ecosystems of partners to drive collaboration and integration of these technologies. One structured and proven way of establishing such an ecosystem is via standardization. Standards provide vehicles to establish best-practices and define interfaces for compliance, allowing users to have confidence that the products they employ are safe, reliable, and are of good quality.
M17 Project has developed a new digital radio protocol for data and voice, made by and for amateur radio operators.
The protocol's voice mode uses the free and open Codec 2 voice encoder. This means there are no patents, no royalties, and no licensing or legal barriers to scratch-building your own radio or modifying one you already own.
This freedom to build, understand, and innovate is core to amateur radio, but has been missing from the commercially available digital voice modes. This is part of why amateur radio digital voice modes have largely stagnated since the 1990s and we're almost wholly dependent on commercial products that aren't well designed for amateur radio users.
Protocol specification can be found here: https://spec.m17project.org/
Erin Bournival is a Distinguished Engineer from the Office of the Corporate CTO at Dell Technologies.
She is an experienced Technologist with a demonstrated history of working in the Information Technology industry. Skilled in system architecture, Virtualization, Storage, the Internet of Things, Digital Twin, and National/International Standards development, Erin illuminates the process of international standardization for a promising open source communications protocol called M17.
Please welcome our speaker.
A
A
Practical
open
source
engineering
is
a
series
of
talks
from
the
san
diego
chapter
of
information
theory,
society
of
the
institute
of
electrical
electronics,
engineers
or
ieee
for
short
ieee
is
the
world's
largest
professional
engineering
society.
Open
research
institute
is
a
non-profit
dedicated
to
open
source
research
and
development
of
digital
radio.
In
all
aspects,
ori
is
the
co-sponsor
of
the
practical,
open
source
engineering
series
and
is
the
fiscal
sponsor
of
the
m17
project
to
learn
more
about
ori's
work.
Please
visit
openresearch.institute
on
the
web.
A
M17
project
development
is
the
subject
of
today's
talk
to
find
out
more
about
m17.
Please
visit
m17
project
dot,
o-r-g
technologies
do
not
grow
and
mature
in
isolation
to
maximize
utilization
organizations,
often
turn
to
ecosystems
of
partners
to
drive
collaboration
and
integration
of
these
technologies.
A
M17
project
has
developed
a
new
digital
radio
protocol
for
data
and
voice
made
by
and
for
amateur
radio
operators.
The
protocol's
voice
mode
uses
the
free
and
open
codec
2
voice
encoder.
This
means
there
are
no
patents,
no
royalties
and
no
licensing
or
legal
barriers
to
scratch.
Building
your
own
radio
or
modifying
one
you
already
own
this
freedom
to
build,
understand
and
innovate
is
core
to
amateur
radio,
but
has
been
missing
from
the
commercially
available
digital
voice
modes.
A
A
She
is
an
experienced
technologist
with
a
demonstrated
history
of
working
in
the
information
technology
industry,
skilled
in
system
architecture,
virtualization
storage,
the
internet
of
things,
digital
twin
and
national
and
international
standards.
Development,
erin,
illuminates
the
process
of
international
standardization
for
a
promising
open
source
communications
protocol
called
m17.
B
B
So,
who
am
I
my
name
is
aaron
bornabel
kilo,
one
echo
november?
Bravo,
I'm
just
today,
I'm
here
speaking,
but
on
behalf
of
myself,
I'm
not
speaking
on
behalf
of
it
down.
If
you
want
me
speaking
on
behalf
of
this
a
different
conversation,
as
michelle
mentioned,
I
spend
a
lot
of
time
in
standards,
development
organizations,
I
chair
a
number
of
groups
on
system
architecture,
the
internet
of
things,
digital
twin
and
other
aspects.
B
So,
let's
start
with
the
definition
of
what
a
standard
is.
This
is
from
iso.org,
and
it's
surprisingly
one
of
the
few
that
I
could
could
find
where
we
say
that
a
standard
is
a
document
or
it's
a
series
of
documents
that
we
established
by
consensus.
Consensus
is
an
agreement
amongst
multiple
people.
We
might
call
it
lack
of
sustained
opposition.
B
What
does
that
mean
exactly?
It
varies
from
committee
to
to
committee.
Sometimes
it
means
that
nobody
is
disagreeing
with
what
you're
saying
and
raising
here
and
saying
so.
Sorry,
sorry,
stop.
I
completely
disagree
with
what
you're
saying
in
other
circles,
it's
possible
for
maybe
one
person
or
two
people
to
disagree,
but
everybody
else
agrees.
B
B
B
It
doesn't
carry
quite
the
same
weight
as
if
a
national
or
international
organization
puts
their
stamp
on
it
says.
Yes,
we
have
followed
all
of
the
processes
that
maximize
the
quality
of
this
document
and
therefore
we
believe
that
this
is
appropriate
for
standardization.
So
technically
it
doesn't
need
that
backing
from
the
recognized
body,
but
it
does
increase
the
quality
quite
a
bit
and
it's
worthwhile
you'll
probably
find
other
definitions
of
a
standard.
B
So
what
if
we
want
to
use
a
standard?
What's
the
purpose
of
it,
we're
looking
to
help
increase
the
use
of
a
technology
we
might
want
to
increase
interoperability?
We
want
to
define
interfaces
that
people
use
and
we
want
some
some
notion
of
weight
to
those
interfaces
so
that
people
know
that
these
are.
This
is
the
the
interface
that
we're
going
to
use
and
everybody
else
is
going
to
use
it
too,
and
I
feel
comfortable
knowing
that
we're
all
using
the
same
interface
standards
could
also
be
guidance.
B
It
doesn't
have
to
be
an
interface
and
again
it's
guidance
that
everybody
agrees
on
and
there's
consensus
in
the
room
that
this
is
the
right
way.
The
right
way
to
do
it
best
practices
would
be
a
great
example,
and
why
else
would
you
want
to
use
standard
you're
looking
to
benefit
from
that
weight
of
the
standard?
From
from
the
fact
that
you
know
that
other
people
are
following
you
in
the
use
of
a
particular
version
of
a
standard
so
that
everybody
will
line
up
their
ducks
in
a
row
together.
B
So
what
kind
of
what
kind
of
standards
do
we
have?
Here's
just
a
few
characteristics.
Some
standards
are
developed
nationally.
For
example,
we
have
some
in
the
united
states.
There's
some
in
germany,
pretty
much
every
country
in
the
world
has
their
own
national
body
who
develops
standards.
We
also
have
international
organizations
like
iso,
that
I
talked
about
a
few
minutes
ago
or
ieee
who
is
hosting
this
session.
B
We
have,
I
was
a
little
hesitant
to
use
the
word,
the
term
full
standard,
but
it
it
probably
it's
probably
good
enough.
This
is
this
would
be
a
very
large
document.
We
have
technical
standards
which
might
be
a
little
bit
smaller.
Some
people
use
the
term
technical
report
that
might
be
closer
to
white
paper
a
little
bit
smaller.
B
It
can
be
as
large
or
small
as
you
want
it
to
be,
as
long
as
it
conveys
the
thoughts
that
you
want
it
to,
and
standards
can
be
free
or
they
could
be
offered
a
nominal
charge
and
the
charge
is
usually
for
it
goes
back
to
this
development
body
who
who
helped
host
the
development
of
the
standard
to
pay
for
things
like
management
staff
and
program
management
and
the
internet,
and
all
the
things
that
they
have
to
pay,
for.
It
does
not
go
back
to
the
people
that
offers
the
standards
generally.
B
I
talked
a
little
bit
about
standardies
and
one
aspect
of
sanity's.
Is
this
notion
of
normative
requirements
when
we
talk
about
normative
requirements,
we're
talking
about
placing
a
requirement
on
the
reader
of
the
document
to
make
them
do
something?
You
don't
want
them
just
to
read
the
document
and
look
and
say
that's
nice
and
put
it
down
and
go
to
something
else.
We
want
them
to
react
to
it.
B
So
this
is
how
we
enforce
compliance
to
make
sure
that
users
are
either
in
compliance
with
a
standard
or
they're,
not
within
compliance
and
there's
three
different
kinds
of
normative
requirements,
and
actually,
I
should
probably
use
a
different
term
for
this,
but
number
the
type
two
two
of
the
types
of
normative
requirements,
one
I
call
numerator
requirements
and
the
other
I
would
call
normative
inclusion.
Number
of
inclusion
would
be
if
I
have
another
document
that
I
want
to
insert
in
line
in
inside
of
an
existing
document.
B
So
I
have
a
vocabulary
standard
that
I
want
to
pull
into
my
document
on
a
protocol.
I
can
do
a
normative
inclusion
and
just
put
one
line
of
text
in
my
standard
and
say
pull
in
that
vocabulary,
standard
and
pull
the
whole
thing
in
here
by
binomial
requirement.
I
mean
that
we
use
language
such
as,
shall
should
may
and
can
for
the
magic
words
which
force
the
reader
to
do
something-
or
at
least
this
helps
them
understand
what
they
have
to
do
in
order
to
be
compliant
with
your
standards
and
notice.
B
The
one
that
trips
everybody
up
is
the
difference
between
man
can
may
means
that
you're
granting
somebody
permission
to
do
something
but
you're
not
saying
much
about
whether
they
should
choose
to
do
it
or
not.
Can
is
the
ability
to
do
something?
It's
a
question
of
mother.
May
I
go
to
the
store,
or
can
I
go
to
the
store?
Do
I
have
a
car?
Yes,
I
can
go
to
the
store,
so
it's
a
little
bit
different
and
it's
one
that
trips
people
up
a
lot,
and
it's
very
interesting
so.
B
Use
the
client
shall
connect
to
the
server
by
udp
on
1700,
probably
resonates
with
this
group.
I
suspect
if
people
are
not
using
udp
on
port
1700,
they
are
not
in
compliance
with
this
standard
flat
out
and
you,
and
I
would
generally
take
the
position
that,
if
you're
not
complying
with
the
standard,
you
need
to
fix
that
problem.
Otherwise,
we
can't
help
you
if
that
makes
sense.
B
Okay,
okay,
so
there's
at
least
a
couple
of
different
types
of
organizations.
I
talked
about
standards,
development
organizations,
there's
also
a
different
type
of
organization
called
either
an
industry
association
or
consortium,
and
these
groups
again
I'm
drawing
a
line
in
the
sand.
Technically,
don't
develop
standards,
they
develop
guidance
because
they're,
not
a
standards,
development
organization.
B
B
B
So,
who
exactly
are
cena's
development
organizations?
There's
some
several
on
the
top
here
you
probably
know
most
of
these,
or
at
least
I've
heard
of
them
at
some
point.
A
lot
of
these
are
international,
although
we
have
ansi,
which
is
in
the
united
states,
and
we
have
den,
which
is
in
germany,
we
also
have
a
number
of
consortium
which
again
tend
to
author
guidance
and,
technically
probably
don't
don't
offer
standards
trying
trying
to
make
this
very
clear
so
that
we
focus
on
the
right
groups.
B
B
B
So
how
can
you
do
this?
How
can
you
take
something
like
a
protocol
that
somebody's
developed
and
make
it
a
standard?
We
start
with
the
choice
of
a
standards,
development
organization.
I
have
listed
two
here
that
I'm
familiar
with
the
paths
on
how
you
could
do
this,
there's
probably
a
comparable
one
in
ieee,
although
I'm
not
familiar
with
it,
I
probably
should
have
listed
it
as
a
as
the
two
do,
the
first
one
which
hopefully
everybody
knows,
is
ietf.
B
B
B
B
The
difference
here
is
that
you
guys
have
already
done
most
of
the
work
for
developing
the
protocol,
and
so
it's
closer
to
a
rubber
stamp
less
than
holding
a
number
of
meetings
over
several
years
and
hammering
out
the
details,
you've
done
most
of
the
work,
and
so
this
is
a
little
bit
different
than
the
way
standards
are
traditionally
done
where
we
start
from.
We
start
from
an
idea
and
actually
gather
people
from
around
the
world
to
develop
a
full
standard
based
off
of
that
idea.
B
Just
a
couple
of
quotes
from
the
ietf
I
love
this
just
kind
of
reflect
shows
a
little
bit
about
how
grassroots
they
are.
The
first
quote
from
david
clark:
we
reject
kings
president
and
voting.
We
believe
in
rough
consensus
and
running
code.
I,
like
that
and
another
quote
from
john
possible
opening
the
right
postal
be
conservative
in
which
you
send
and
liberal
in
what
you
accept.
B
Something
that
you
wanted,
that
you
thought
this
was
a
good
idea.
You
could
choose
an
organization
and
start
a
discussion
with
them
about
how
you
might
achieve
this.
You
would
identify
the
deliverables
that
you
want
to
to
standardize.
They
could
be
a
protocol
spec.
It
could
be
a
guidance
spec,
whatever
you've
got
in
the
m17
project,
that
you'd
want
to
do
again,
connect
to
the
organization
find
out
the
right
committee
that
would
be
responsible
for
helping
you
make
this
happen.
B
What
you
have
probably
is
not
a
standard,
although
it
might
be
close,
and
it
might
just
be
a
little
bit
of
finessing
of
the
language
just
to
make
sure
that
it
is
expressed
appropriately
as
a
standard,
and
then
you
figure
out
a
really
schedule.
How
often
do
you
want
to
release
updates
new
additions
to
your
standard?
Do
you
want
to
do
it
every
year?
Is
it
after
major
functional
releases?