Subject: Re: [dtn] dtn wg work items

From: Martin Stiemerling <[email-masked]>
Date: Thu, 08 Jan 2015 10:02:59 +0100

Hi all,

Sorry for the delay in replying.

I am in principle ok with the work items of phase 1.

However, the charter says (with good intention):
"Agree to a list of use cases for evolving the DTN specifications and 
a list of work items to be worked on."

The list of work items is the second step IMHO, as the WG has to agree 
on a list of use cases that are considered in the first phase, before we 
can really agree on the list of work items.

I assume that the below phase 1 list is based on use cases, but I would 
like to see the description of the use cases, either as an email to the 
list or in a draft. We do not take these drafts as WG items, but can 
have them as record of documentation in the progress of the WG.

With respect to phase 2: I don't see that the WG can successfully talk 
right now about phase 2 at this point of time, as the work items list in 
phase 1 is already exhaustive and I assume that the work in phase 1 will 
result in a different phase 2 list.

A happy new year!

   Martin

Am 17.12.14 um 20:34 schrieb Marc Blanchet:
> Martin, as AD for dtn wg,
>   here is the agreement of work items that the working group have concensus on. We are looking to get your approval so we can move forward on the technical work.
>
> Regards, Marc&Brian
>
> ===============
> DTN Work Items
>
> Phase 1
>
> 1 Integrity and Immutability
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a header integrity
>     b payload integrity
>     c e2e integrity
>     d immutability of primary block
>     e remove dictionary
>     f bundle size
> 2 Improved Security
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a Determine if SBSP is starting point
>     b Identify dependency on header changes
> 3 Addressing
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a develop requirements on addressing from use cases
>     b narrow scope of work
>     c Possible interim meeting
> 4 Node/Neighbor Discovery
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a Investigate MANET discovery protocol model
>     b Assess applicability of draft-irtf-dtnrg-ipnd
> 5 Static Routing
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a Assess relationship to node/neighbor discovery
> 6 Avoid Routing Loops
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a assess applicability of draft-fall-dtnrg-schl-00
> 7 Time and bundle expiration
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a assess applicability of draft-irtf-dtnrg-bundle-age-block-01
> 8 Improve Specifications such as RFC 5050
>   ◦ Status: DTN WG work item
>   ◦ Considerations:
>     a fix known specification bugs
>     b constrained environments
>     c default operations
>     d simplify options
>     e identify issues for incompatibilities with 5050
> 9 Registry of Service Identifier
>   ◦ Status: DTN WG work item.
>
> =======
> Phase 2
> (after phase 1 completed, potential work items below. list to be reviewed at that time)
> 1 Network Management
>   ◦ Network monitoring only, not configuration
>   ◦ Considerations:
>     a Potentially interface with LIME WG
>     b Move configuration to DTNRG?
> 2 Key management
> 3 Extended Class of Service
> 4 Multicast
> 5 Streaming Support
>
> ========
> Non Work Items
> 1 Dynamic Routing
>   ◦ Status: suggesting DTNRG
>
>
>
>
>

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 8 Jan 2015 07:52:22 -0500

> Le 2015-01-08 à 04:02, Martin Stiemerling <[email-masked]> a écrit :
> 
> Hi all,
> 

good.

> "Agree to a list of use cases for evolving the DTN specifications and a list of work items to be worked on."
> 
> The list of work items is the second step IMHO, as the WG has to agree on a list of use cases that are considered in the first phase, before we can really agree on the list of work items.
> 
> I assume that the below phase 1 list is based on use cases,

use cases have been part of the discussions but were not fully documented.

> but I would like to see the description of the use cases, either as an email to the list or in a draft. We do not take these drafts as WG items, but can have them as record of documentation in the progress of the WG.

Let’s see if we can find editors for use cases. I would like to just say that while it is good to have a perfect use-case -> work items -> document process (and I always agreed in principle on this, and the bof agenda was constructed that way), we may end up loosing energy in the working group, if we are way too picky. So a good balance here is needed.

> 
> With respect to phase 2: I don't see that the WG can successfully talk right now about phase 2 at this point of time, as the work items list in phase 1 is already exhaustive and I assume that the work in phase 1 will result in a different phase 2 list.

that was the intent. the list of « phase 2 » is essentially a placeholder for topics that we talked about but were not getting concensus to work on initially. So we will discuss these later.

Marc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 16:06:44 +0000

Hi,

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
> Sent: Thursday, January 08, 2015 4:52 AM
> To: Martin Stiemerling
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dtn] dtn wg work items
> 
> 
> > The list of work items is the second step IMHO, as the WG has to agree on a list of use cases that are considered in the first phase,
> before we can really agree on the list of work items.
> >
> > but I would like to see the description of the use cases, either as an email to the list or in a draft. We do not take these drafts as WG
> items, but can have them as record of documentation in the progress of the WG.
> 
> Let’s see if we can find editors for use cases. I would like to just say that while it is good to have a perfect use-case -> work items ->
> document process (and I always agreed in principle on this, and the bof agenda was constructed that way), we may end up loosing
> energy in the working group, if we are way too picky. So a good balance here is needed.

I agree with Marc, and can volunteer to work on a use case document. Individual Submission?

Thanks - Fred
[email-masked]

> > With respect to phase 2: I don't see that the WG can successfully talk right now about phase 2 at this point of time, as the work items
> list in phase 1 is already exhaustive and I assume that the work in phase 1 will result in a different phase 2 list.
> 
> that was the intent. the list of « phase 2 » is essentially a placeholder for topics that we talked about but were not getting concensus
> to work on initially. So we will discuss these later.
> 
> Marc.
> 
> >
> > A happy new year!
> >
> >  Martin
> >
> >
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Brian Haberman <[email-masked]>
Date: Thu, 08 Jan 2015 11:27:42 -0500

> I agree with Marc, and can volunteer to work on a use case document. Individual Submission?

I would prefer the WG wiki.  The use cases may change and we want them
to reflect the current set as work is done on the actual protocol.
Pushing them out as an RFC (IETF or ISE) is too heavyweight and sets
them in stone.

Regards,
Brian

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 8 Jan 2015 11:29:03 -0500

> Le 2015-01-08 à 11:06, Templin, Fred L <[email-masked]> a écrit :
> 
> Hi,
> 
> 

good! thanks!

I think
a) optimally, we should have a few editors on this to represent the different needs of the industries
b) we are specifically requested _not_ to create a draft document. I wonder if editors could use google docs (or else) to do this work. I found that during our thread on work items that the use of google docs with the facilities of formatting and interactive editing was really efficient. (but I don’t care of tools, but on the content and efficiency of editors and wg. 

Marc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 18:15:19 +0000

Hi Brian,

Good suggestion on the wiki - I went ahead and added the use case information there:

https://tools.ietf.org/wg/dtn/trac/wiki#

The wiki interface itself is somewhat clumsy and maybe not the best place to do
extensive editing. On the other hand, I can access it from my workplace which is
not the case for google docs.

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Thursday, January 08, 2015 8:28 AM
> To: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 18:20:08 +0000

Hi Marc,

> Sent: Thursday, January 08, 2015 8:29 AM
> To: Templin, Fred L
> Cc: Martin Stiemerling; [email-masked]; [email-masked]

As I just replied to Brian, I posted the use case materials I presented in Honolulu on the wiki:

> b) we are specifically requested _not_ to create a draft document. I wonder if editors could use google docs (or else) to do this work. I
> found that during our thread on work items that the use of google docs with the facilities of formatting and interactive editing was
> really efficient. (but I don’t care of tools, but on the content and efficiency of editors and wg.

I cannot access google docs from my workplace - not permitted by corporate policy.
On the other hand, working with the wiki GUI is very cumbersome. So, I am not sure
what to do at this point. Thoughts?

Thanks - Fred

---

From: "Juan A. Fraire" <[email-masked]>
Date: Thu, 8 Jan 2015 15:27:22 -0300

Hi Fred,

Looks like an interesting summary of DTN use cases. Thanks for putting it
together.

I suggest also considering Lasser Comms (Space Systems Communications) as
potential beneficiary of DTN as well. Laser guys from NASA (LADEE/LLDD)
were having severe disruption due to laser depointing and clouds that were
somehow counteracted with DTN.

Best Regards,

J.Fraire

On Thu, Jan 8, 2015 at 3:20 PM, Templin, Fred L <[email-masked]>
wrote:

> > b) we are specifically requested _not_ to create a draft document. I
> wonder if editors could use google docs (or else) to do this work. I
> > found that during our thread on work items that the use of google docs
> with the facilities of formatting and interactive editing was

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 18:48:07 +0000

Hi Juan,

Thanks for the good suggestion. Not just for space systems laser comms, but also free space
optics in all domains are affected by atmospheric conditions like cloud cover, rain fade, etc.
Other high-frequency RF comms are also similarly affected. Can we therefore consider  this
use case as applying across multiple domains?

Thanks – Fred

From: Juan A. Fraire [mailto:[email-masked]]
Sent: Thursday, January 08, 2015 10:27 AM
To: Templin, Fred L
Cc: Marc Blanchet; Martin Stiemerling; [email-masked]; [email-masked]
Subject: Re: [dtn] dtn wg work items

Hi Fred,

Looks like an interesting summary of DTN use cases. Thanks for putting it together.

I suggest also considering Lasser Comms (Space Systems Communications) as potential beneficiary of DTN as well. Laser guys from NASA (LADEE/LLDD) were having severe disruption due to laser depointing and clouds that were somehow counteracted with DTN.

Best Regards,

J.Fraire

On Thu, Jan 8, 2015 at 3:20 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Marc,

> From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Marc Blanchet
> Cc: Martin Stiemerling; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > Le 2015-01-08 à 11:06, Templin, Fred L <[email-masked]<mailto:[email-masked]>> a écrit :
> >
> > Hi,
> >
> >

https://tools.ietf.org/wg/dtn/trac/wiki#<https://tools.ietf.org/wg/dtn/trac/wiki>

Thanks - Fred
[email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>
_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 8 Jan 2015 19:24:38 +0000

I vehemently disagree that UAS in the National Airspace is a Use Case.  It
IS NOT.  Links are 99.8 percent available.  Loss of link is really really
bad.  Assumed to be hardware failure.

All operation are pilot-in-the-loop.   I can add the following to the wiki
to support my claims.  NASA Glenn is heavily involved in the
communications aspects of UAV in the NASA.  The FAA may find statements
that DTN will be used for Air Traffic Control quite troubling.

I obtained the following information from the communications lead for UAS
in the NAS

http://www.nasa.gov/topics/aeronautics/features/uas_prototype_radio.html#.V
K7XNUjQ4dU

On 1/8/15 1:49 PM, "Griner, James H. (GRC-LCA0)" <[email-masked]> wrote:

>Attached is the availability document, RTCA SC-203 Issue Paper.  It's not
>a published document per say, but was peer reviewed and is one of our
>guiding documents.
>
>
>UAS are intended to Operate in the Same Airspace as Commercial Aviation
>
>
>For all operations in the significant future UAS will be
>pilot-in-the-loop, i.e. no autonomous operations.  Therefore DTN is not
>useful.
>
>
>
>Jim

Key CNPC System Level Requirements

   Requirement

   Source

  Radios must
  operate in frequency bands 960  977 MHz (L band) and   5030  5091 (C
band)

  WRC-12

  
  L band and C
  band operations must be independent

  NASA GRC

  
  RF link
  availability for any single link >= 99.8%
  Availability
  for simultaneous operation of L band and C band >= 99.999%

  RTCA SC-203
  CC016

  
  Non-proprietary
  waveform

  NASA GRC

  
  Must operate
  both air-to-ground and ground-to-air modes

  NASA GRC

  
  Aircraft
  density assumptions
     Small UAs = 0.000802212 UA/ km^2
     Medium UAs =
  0.000194327 UA/ km^2
     Large UAs = 0.00004375 UA/  km^2

  ITU-R M.2171
  P.54

  
  Cell Service
  Volume Radius = 75 miles (L-Band)

  RTCA SC-203 CC016

  
  Maximum
  number of UAs supported per cell = 20 (basic services)
  Maximum
  number of UAs supported per cell = 4 (weather radar)
  Maximum
  number of UAs supported per cell = 4 (video)

  RTCA SC-203
  CC019

  
  Tower height
  = 100 feet

  Rockwell
  Assumption

  
  Uplink
  Information Rates (Ground-to-Air)
     Small UAs = 2424 bps
     Medium and Large UAs = 6,925 bps

  ITU-R M.2171
  Table 13

  
  Downlink
  Information Rates (Air-to-Ground)
     Small UAs (basic services only) = 4,008
  bps
     Medium and Large UAs (basic services only)
  = 13,573 bps
     Medium and Large UAs (basic and weather
  radar) = 34,133 bps
     Medium and Large UAs (basic, weather radar
  and video) = 234,134 bps

  ITU-R M.2171
  Table 13

  
  Frame rate
  must support 20 Hz to enable real time control

  ITU-R M.2171
  Table 23/24

  
  Aviation
  Safety Link Margin = 6 dB

  RTCA SC-203
  CC019

  
  Airborne
  radio transmit power = 10 W

  RTCA SC-203
  CC019

>From RTCA SC-203 Issue Paper
This paper discusses the DO-264 Required
Communications Performance parameter Availability for the concept UAS
Control and Communications Architectures described
in SC203-CC005_UAS Control and Communications Architectures UAS.

With regard to
unrecoverable hardware failure leading to a lost link, and in
the absence of autonomous separation assurance and collision
avoidance systems, the operational
response for the UA would be an automatic
return to base or automatic recovery (or flight termination) at
another location. This process cannot take less than several minutes,
and could potentially take many tens of minutes or even several hours. If
the
NAS has been augmented with a nominally cleared flight level, where most
aircraft do not normally operate except while transitioning altitude, the
UA
might attempt to autonomously climb or descend to this
nominally cleared flight level and operate there for a
portion of its remaining flight (i.e., until it reaches
the pre-planned location for automatic recovery/landing or flight
termination).
>From the
perspective of the NAS, the lost link is presumed
to be announced by both the UA and the UA control station. The UA will
squawk lost
link via its radar transponder and ADS-B system.[1] <#_ftn1> The UA Control
Station will independently inform
ATC  either by voice communication between the UA pilot and Air Traffic
Controller, or by a suitable data message. Hence there
are multiple methods by which ATC will be informed of the lost-link
situation. Positive
surveillance of the UA is based on primary/secondary radar and ADS-B, and
will
continue despite the loss of control link communications between
the UA and the UA pilot. It is
presumed that ATC, informed of the lost link situation and aware of
the UA location and altitude, will take positive steps
to ensure safety and compensate for the
lack of pilot-in-the-loop SAA. These positive steps might
include notifications to manned aircraft in the vicinity (and UA pilots
operating unmanned aircraft in the vicinity), or even a prophylactic
clearing
of the local airspace (if feasible).
>From the standpoint of
collision risk, there is an ³exposure interval² of increased risk which
opens
with the onset of the hardware failure and closes with the occurrence of:
a)
automatic recovery or flight termination; or b) autonomous
UA navigation to a nominally cleared flight level; or
c) prophylactic clearing or ³safing² of the local
airspace by ATC. The expected duration of the exposure interval
places a limit on the tolerable likelihood of the lost link scenario itself
(and therefore the required hardware availability). For example,
if the entire ³unavailability risk² is assigned to hardware failure
(ignoring
RF and network-related outages), and the expected exposure interval is one
hour, a UA attempting to achieve equivalent Part 91
operations (assessed unavailability budget = 10-3
from Section 2.1 above) would need to achieve mean
time between hardware outages (MTBO) of 1000 hours. A UA
attempting to achieve equivalent Part 121 operations (assessed
unavailability
budget = 10-5 from Section 2.1 above) would need to achieve mean
time between hardware outages (MTBO) of 100,000 hours. A more
realistic apportionment of the unavailability budget, with the majority of
the
budget reserved for short-term outages, would drive these MTBO thresholds
to
higher values  perhaps 10,000 hours and 106 hours
for Part 91 and Part 121 operators, respectively.

________________________________________
[1] <#_ftnref1> A
unique transponder code is needed to differentiate between loss of voice
communications with ATC, versus loss of control link communications with
the UA
Control Station. This is presumed to exist in the time frame of UA
operations in the NAS. The UA would be able to detect loss of control link
and
autonomously set the transponder code (as well as the equivalent ADS-B
outgoing
message field).

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 20:24:16 +0000

Hi Will,

> From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
> Sent: Thursday, January 08, 2015 11:25 AM
> To: Templin, Fred L; Brian Haberman; [email-masked]

About data link availability, the document you pointed to says:

  "The way radio waves move through the air can be affected by a number of different things,
  including whether the ground is covered with leafy trees or snow and ice. Mountains, oceans,
  weather conditions, urban sprawl, skyscrapers and more can cause a change in a radio signal,
  for a good or bad."

When rich data link capabilities are available, you are correct that direct use of
traditional comms over the available links is preferable to using DTN. However,
loss of comms and/or intermittent comms are an inevitable condition that must
be dealt with. There is no such thing as a "perfect" aviation use case data link.

> that DTN will be used for Air Traffic Control quite troubling.

Loss of comms and/or intermittent comms is an inevitable condition that must
be accounted for. The old way was for the UAS to fly itself into the ground in a
loss of comms condition. With DTN, we should be able to do better than that.

You also cite pilot-in-the-loop, but we are more and more being asked to consider
autonomous operation - AFAICT, the eventual emergence of autonomous UAS
is inevitable.

The FAA document I cited is here:

http://www.gpo.gov/fdsys/pkg/CRPT-112hrpt381/pdf/CRPT-112hrpt381.pdf

Thanks - Fred

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 8 Jan 2015 22:09:19 +0000

>http://www.gpo.gov/fdsys/pkg/CRPT-112hrpt381/pdf/CRPT-112hrpt381.pdf

This is one of the documents we are bound to work under.  It is from
February 2012. 

I find nothing in this document that indicates autonomous operations.
Quite the contrary.  It states that the FAA shall establish safe
operations to integrate UAS in the NAS.  See Subtitle B sections 331 -
336. The results are what I have presented.

If you want to say that in your personal opinion (AFAICT stands for As Far
As I Can Tell) that "the eventual emergence of autonomous UAS is
inevitable." fine. But don't say the Unmanned Air Systems (UAS) in the
National Air Space (NAS) FAA: UAS
integrated into the NAS by 2015 (FAA Modernization and Reform Act) is a
DTN use case, because it is not.

Will

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 22:34:37 +0000

Hi Will,

Regarding the leading portion of my message:

=> About data link availability, the document you pointed to says:
=>
=> "The way radio waves move through the air can be affected by a number of different things,
=>   including whether the ground is covered with leafy trees or snow and ice. Mountains, oceans,
=>  weather conditions, urban sprawl, skyscrapers and more can cause a change in a radio signal,
=>  for a good or bad."

In my understanding, UAS in the NAS applications could include:

  1) forest fire fighting (leafy trees)
  2) avalanche monitoring (snow and ice)
  3) search and rescue (mountains, oceans)
  4) tornado/hurricane tracking (weather conditions)
  5) air support for law enforcement (urban sprawl, skyscrapers)
  ...

All of these are instances where disruptions could naturally result in signal intermittence
and/or loss of comms, and they must be dealt with within the national air space.

Thanks - Fred

> Sent: Thursday, January 08, 2015 2:09 PM

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 8 Jan 2015 22:49:27 +0000

All of those are pilot-in-the-loop.

I reiterate:  Link availability requirement is 99.8% or better.
Communication link design takes into effect all the aforementioned.

>From RTCA SC-203 Issue Paper: UAS Control and Communications Link
Performance 
Availability

2.2.2 Short-Term Link Outages Due To RF and Network Effects

In addition to the hardware failures that
can lead to a lost link, the antennas on the aircraft are assumed to be
imperfect from a coverage standpoint. Hence any single antenna might
³fail² for
a short period of time due to airframe shadowing, destructive interference
due
to multipath reflections off the fuselage, or inability to point in a
necessary
direction.[1] <#_ftn1>

Soft failures might also occur due to temporary degradation of the RF
channel
(excess noise or interference), or temporary degradation of the network
(sync
failure, blockage, routing error). These soft failures due to UA antenna
performance, RF link, and network, are fundamentally different from
hardware
failures since these soft failures are typically of short duration. The UA,
and other aircraft in the vicinity, are ³exposed² during these
short-term outages since neither the UA nor the NAS (ATC) can respond over
short time scales in a way that reduces collision risk. Hence
the system must be designed to ensure that these soft failures are short
(typically less than one second in duration) and infrequent.

________________________________________
[1] <#_ftnref1>
In contrast, the ground segment towers (access points) are assumed to free
of
coverage gaps, so only hardware failures are considered for the ground
segment.

On 1/8/15 5:34 PM, "Templin, Fred L" <[email-masked]> wrote:

>> >You also cite pilot-in-the-loop, but we are more and more being asked
>>to
>> >consider

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 23:08:53 +0000

Hi Will,

> Sent: Thursday, January 08, 2015 2:49 PM

There is no way to ensure that laws of physics can be mitigated in less than one
second duration, e.g.:

 - a UAS supporting a law enforcement operation ducks behind a skyscraper
   and stays there for many seconds or longer, then flies into a news helicopter
  - a UAS fighting a fire in the hills above downtown Los Angeles goes into a canyon
    only to re-emerge in the  path of a commercial airliner descending into LAX
 -  a weather monitoring UAS flies into the eye of a hurricane and pops back
    out again who-knows-where

If the signal is intermittent due to atmospheric conditions, terrain features, or
whatever there are no written regulations that can mandate failures to
persist for less than one second in duration.

Thanks - Fred

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 8 Jan 2015 23:09:31 +0000

http://www.nasa.gov/images/content/654655main_control.jpg

NASA Globalhawk UAV control room.

Back of room closest part  of picture show are the Principal Investigator for NASA Atmospheric Research - Most likely Hurricane mission.  (I was present for Hurricane Karl mission - part of GRIP).

Behind the glass (front of room) are the Global Hawk pilots.  Note, Global Hawk does not fly in the National Airspace System.  It takes off from restricted airspace, lands in restricted airspace (Edward AFB) and flies at 65,000 feet which is above commercial traffic.

The forest fire monitoring stuff flies out of Edwards / Dryden (now Armstrong Research Center at Dryden Field).
http://www.nasa.gov/offices/ipp/centers/dfrc/news_events/SS-Ikhana.html#.VK8MA0jQ4dU

Very close coordination with FAA to clear airspace for the UAV operations.  The Ikhana flies at relatively low altitude compared with the Global Hawk - particularly when doing forest fire monitoring. The Ikhana is able to fly up to 40,000 feet. Thus the need to clear airspace over the fire area to avoid collisions.

The point of UAS in the NAS it so integrate the UAVs so one doesn't have to clear airspace and cargo and such can come in via unmanned, yet piloted, aircraft.

It is all about safety of flight, safety of life.

Will

On 1/8/15 5:49 PM, "Ivancic, William D. (GRC-LCA0)" <[email-masked]<mailto:[email-masked]>> wrote:

On 1/8/15 5:34 PM, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Will,

=> About data link availability, the document you pointed to says:
=>
=> "The way radio waves move through the air can be affected by a number
of different things,
=>   including whether the ground is covered with leafy trees or snow and
ice. Mountains, oceans,
=>  weather conditions, urban sprawl, skyscrapers and more can cause a
change in a radio signal,
=>  for a good or bad."

All of these are instances where disruptions could naturally result in
signal intermittence
and/or loss of comms, and they must be dealt with within the national air
space.

Thanks - Fred

-----Original Message-----
From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
Sent: Thursday, January 08, 2015 2:09 PM
To: Templin, Fred L; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] dtn wg work items
to
If you want to say that in your personal opinion (AFAICT stands for As
Far

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 23:17:04 +0000

Hi Will,

> The point of UAS in the NAS it so integrate the UAVs so one doesn't have to clear airspace and cargo and such can come in via unmanned, yet piloted, aircraft.

Piloted or not, reliable comms are necessary even during periods of disruption.

> It is all about safety of flight, safety of life.

Sure, which is exactly why disruption-tolerant comms are necessary, as proven
by my examples.

Thanks - Fred

From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]] 
Sent: Thursday, January 08, 2015 3:10 PM
To: Ivancic, William D. (GRC-LCA0); Templin, Fred L; Brian Haberman; [email-masked]
Subject: Re: [dtn] dtn wg work items

Will

On 1/8/15 5:49 PM, "Ivancic, William D. (GRC-LCA0)" <[email-masked]> wrote:

Performance 
Availability

Hi Will,

Thanks - Fred

-----Original Message-----
From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
Sent: Thursday, January 08, 2015 2:09 PM
To: Templin, Fred L; Brian Haberman; [email-masked]
Subject: Re: [dtn] dtn wg work items
to

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 8 Jan 2015 23:17:25 +0000

The first two are all illegal operations.  The whole point of UAS in the
National Airspace System work - to ensure safety and make sure these
things do not happen.

The hurricane example: either the aircraft communication system would be
designed to handle the communications link, or the airspace would be
cleared to ensure safe operations.

Will

---

From: Eric Travis <[email-masked]>
Date: Thu, 8 Jan 2015 18:21:03 -0500

Gentlemen,

To be continued (if necessary) in a retitled thread?  ☺

Eric
(who is equally guilty of re-vectoring Ed's ID thread)
On Jan 8, 2015 6:09 PM, "Ivancic, William D. (GRC-LCA0)" <
[email-masked]> wrote:

>  Back of room closest part  of picture show are the Principal
> Investigator for NASA Atmospheric Research - Most likely Hurricane mission.
>  (I was present for Hurricane Karl mission - part of GRIP).
>
>  Behind the glass (front of room) are the Global Hawk pilots.  Note,
> Global Hawk does not fly in the National Airspace System.  It takes off
> from restricted airspace, lands in restricted airspace (Edward AFB) and
> flies at 65,000 feet which is above commercial traffic.
>
>  The forest fire monitoring stuff flies out of Edwards / Dryden (now
> Armstrong Research Center at Dryden Field).
>
>  Very close coordination with FAA to clear airspace for the UAV
> operations.  The Ikhana flies at relatively low altitude compared with the
> Global Hawk - particularly when doing forest fire monitoring. The Ikhana is
> able to fly up to 40,000 feet. Thus the need to clear airspace over the
> fire area to avoid collisions.
>
>  The point of UAS in the NAS it so integrate the UAVs so one doesn't have
> to clear airspace and cargo and such can come in via unmanned, yet piloted,
> aircraft.
>
> From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]
> <[email-masked]>]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2015 23:22:52 +0000

Hi Will,

> Sent: Thursday, January 08, 2015 3:17 PM

You can't mitigate laws of physics with legislation. Once we put UAS in
that NAS, they are subject to comms disruptions regardless of whatever
the laws say.

> cleared to ensure safe operations.

The whole point of UAS in the NAS is to ensure that UAS can operate in the
same air space as commercial and general aviation without having to segregate
the airspace. Once that happens, UAS will need to mitigate comms disruptions
(either manned or unmanned).

Thanks - Fred

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 8 Jan 2015 19:12:02 -0500

> Le 2015-01-08 à 17:09, Ivancic, William D. (GRC-LCA0) <[email-masked]> a écrit :
> 
>> 
>> 
>> 

I would like to add to this conversation that this working group is not focusing on US, but international.

Marc.

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 9 Jan 2015 13:23:16 +0000

Hi Marc,

 This is my last comment on the subject.

Air traffic control is an international matter. Unmanned aircraft are a
new technology relative to air traffic control. The international civil
aviation organization (ICAO) is the organization that handles
international requirements. ICAO  is currently watching what happens in
the US and in particular will be decided upon by the Radio Technical
Commission for Aeronautics (RTCA) organization. Here's a link to the
latest document I can find.

http://www.icao.int/Meetings/UAS/Documents/Circular%20328_en.pdf

 Note, all frequencies assigned to aeronautics are approved by the
international telecommunication Union which is part of the United Nations.

Will

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 9 Jan 2015 08:49:23 -0500

> Le 2015-01-09 à 08:23, Ivancic, William D. (GRC-LCA0) <[email-masked]> a écrit :
> 
> 
>> 

sorry, I hope I did not trigger this silence. We want good engineering discussions.

> international telecommunication Union which is part of the United Nations.

again, my point is that we should make sure we have an international scope. It is certainly ok to talk about what is going on in any country, but I would like to make sure we have a picture of other countries.

Marc.