DTN在卫星通信中的实际测试
12-16
dtn interest的邮件列表上有人发的，不过只是一个测试
=
The following a status of some recent tests - very recent.
We have learned quite a lot in the past month and in particular during
the past two days regarding operations of a global DTN network. We will
be getting our lessons learned documented and send those out. Items
such as time synchronization and better ways to ensure bundle don't live
forever are just a few of the items we will address.
Three SSTL UK-DMC Satellite passes were taken on 25 January 2008 to test
the latest NASA/Cisco/SSTL build of Saratoga/DTN bundling.
The passes occurred as follows:
07:54 - 08:07 UTC 28 deg elev
09:31 - 09:45 UTC 45 deg elev
11:12 - 11:21 UTC 5 deg elev
Information on the SSTL disaster monitoring satellites is here:
http://www.sstl.co.uk/index.php?loc=120
And the UK-DMC with the Cisco Router is here:
Note, the router was not used for these tests. The code is written
directly to RTEMS on the Solid State Data Recorder Stack. Only those
portions necessary to create bundles were written into RTEMS. The
smarts where placed on the ground. All of this will eventually be
documented in a formal report and papers. This is most definitely work
in progress.
http://www.sstl.co.uk/index.php?loc=113
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/
ftp://ftp-eng.cisco.com/lwood/cleo/README.html
============================================
DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
1) Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
Station
2) Demonstrate that DTN code and general SSTL code can coexist
without effecting normal SSTL Operations
Configuration
* UK-DMC acquired a150 Mbyte image over the Gulf of Khambhat,
India at ~04:35 UTC on 25 January 2008.
* DTN bundling code default set to 80 Mbytes for proactive
fragmentation
Tests
1) Basic file download using existing technique (Saratoga)
2) Same file downloaded but treated as single bundle (DTN)
3) Same file download but using DTN proactive fragmentation with 80
Mbytes preconfigured fragments.
=============================================
Executive Summary:
The passes where successful in the fact that we learned a lot and
identified some bugs. On the surface, these bugs appear to be minor and
relatively easy to correct. Thus, for a first try, we should all be
please.
For the most part, DTN bundling and forwarding worked but we appear to
have a bug in the GRC implementation of Saratoga regarding filling holes
in missed data. In addition, there may be a bug in the DTN-2 code
implementation on the SSTL bundling agent as on bundle got stuck in a
temporary file and was never transferred from SSTL to GRC.
It appears that on the first pass, tests 1 and 2 were successful
regarding operation of DTN and the ability to either use either Saratoga
for straight file transfers or Saratoga with bundling to transfer DTN
bundles between the UK-DMC solid state data recorder and the ground.
Also the DTN-2 forwarding agent, Bundling-SSTL was able to automatically
forward the DTN bundles to a DTN-2 bundling agent at Glenn Research
Center, Bundling-GRC1. Furthermore, we could then extract the image
file from the DTN bundle.
==============================================
Detailed Analysis:
The image files for 25 January 2008 tests are available at the following
URL:
(Link Removed)
Investigation of these show each image file has "holes" in different
portions of the file.
The simplified test configuration is show in the figure below.
UK-DMC
(Bundling Only)
+------+,-.+------+
| | | |
+------+`-'+------+
.'
.'
.' Saratoga Transport
.' Over UDP
| .'
'..'
.\ `..
.i__i.
+----------+ +----------+
| Bundling | __________________________| Bundling |
| SSTL |' TCP Transport | GRC1 |
+----------+ +----------+
DTN-2-Based DTN-2-Based
Modifications
- Large files
- DTN Client to pull bundles
From UK-DMC (smarts on the ground)
Pass 1, Test 1:
The Image file DU00076pm was received using Saratoga at the
Bundling-SSTL, the DTN bundle agent at SSTL.
Pass 1, Test 2:
The DTN file and associated metadata for the full bundle was received by
Bundling-SSTL and then forwarded as a full bundle to Bundinging-GRC1
The file was then extracted from the bundle and saved as
"bundling-file".
We performed a "diff" between "saratoga-file" and "bundling-file" and
the result showed mismatch, but no detail on what was mismatched.
Post analysis showed "holes" in both the files brought down using
Saratoga for file transfer and Saratoga for bundle transfer. We suspect
a problem with the GRC implementation of Saratoga. We suspect a
problem in the perl code. This is the first place GRC will investigate
as that code is related to the hole filling. We did not really stress
the testing of that (hole filing) in the lab as we were running
error-free links. The pattern of holes in different places of each
image transfer leads us to suspect the "holes to fill" portion of the
code. That probably explains the main difference regarding file mismatch
between the first and second passes from the standpoint of that part of
the experiment. That would also explain why the Saratoga-only transfer
doesn't match the DTN one.
Pass 1, Test 3 - Proactive Fragmentation:
While running Saratoga on Bundling-SSTL we retrieved the directory and
the syslog file. The directory showed creation of the 1st fragmentation
metadata file, but not the second. We retrieved the 1st proactive
fragmented bundle from the UK-DMC and it was automatically transferred
using DTN-2 between Bundling-SSTL to Bundling-GRC1.
Upon investigation of the syslog, it appears that the 2nd metadata
proactive fragmentation metadata file was created, but the file could
not be written. Upon discussion with SSTL and investigation, it appears
the 2nd metadata file length was to be 33 characters and 32 characters
is the current limit.
* One possible way is to fix this is to recompile RTEMS such that
longer file names are allowed. Since this only effects the DTN
proactive fragmentation this may be acceptable.
* Another possible solution is to have the default file name less
than 10 characters. However, this changes SSTL's default naming system.
* A third way is to rethink how the proactive fragmentation files
are named. The long length is caused by the naming convention used
where the fragmentation metadata files and associated bundles are name
as "filename.startoffset-endoffset.dtn". Here, the start offset is the
location in memory where Saratoga should begin capturing data and the
end offset is the location where Saratoga should stop capturing data.
We will discuss possible solutions with SSTL.
Example file names:
SSTL full image = DU000c76pm
Fragment 1 (80 Mbytes) = DU000c76pm.0-79999999.dtn (25 characters)
Fragment 2 (70 Mbytes) = DU000c76pm.79999999-153700328.dtn (33
characters)
Pass 2, Test 1:
The Image file DU00076pm was received using Saratoga at the
Bundling-SSTL, the DTN bundle agent at SSTL. However, post processing
showed holes in the image file (long strings of zeros).
Pass 2, Test 2:
The DTN metadata file for the full bundle was received as was the DTN
file. However, this data was written to a temporary file and never pass
on to the DTN bundle forwarding portion of the code. Thus, the bundle
was never transferred from Bundling-SSTL to Bundinging-GRC1.
After the fact, we manually retrieved the bundle from the temporary
storage location and extracted the file. Thus, the bundle was moved
from the UK-DMC to SSTL bundling agent at the ground and then got stuck
in memory. This may take some time to troubleshoot.
Pass 2, Test 3 - Proactive Fragmentation:
While running Saratoga on Bundling-SSTL we retrieved the directory and
the syslog file. The directory showed creation of the 1st fragmentation
metadata file, but not the second. We retrieved the 1st proactive
fragmented bundle from the UK-DMC and it was automatically transferred
using DTN-2 between Bundling-SSTL to Bundling-GRC1. Thus, results were
identical to Pass1, Test 3.
Pass 3:
During the third pass of the day, GRC personnel went home to sleep and
SSTL personnel transferred the image using SSTL's version of Saratoga.
The image transferred in tact with no holes.
========================================
Next Steps to fix technical problems:
1) Induce errors into the space-to-ground and ground-to-space links
of the engineering test system and troubleshoot the "hole filling"
problem. The capability currently exists and just has to be turned on.
2) Fix the fragmentation problem associated with the long naming.
This should be relatively easy, but which approach needs to be discussed
with SSTL.
3) Analyze and investigate why the DTN bundle got trapped in
temporary storage locations on the SSTL bundle forwarding agent. This
may take some time. Our files were quite large - 150 Mbytes. This
large size may have something to do with the problem.
=
The following a status of some recent tests - very recent.
We have learned quite a lot in the past month and in particular during
the past two days regarding operations of a global DTN network. We will
be getting our lessons learned documented and send those out. Items
such as time synchronization and better ways to ensure bundle don't live
forever are just a few of the items we will address.
Three SSTL UK-DMC Satellite passes were taken on 25 January 2008 to test
the latest NASA/Cisco/SSTL build of Saratoga/DTN bundling.
The passes occurred as follows:
07:54 - 08:07 UTC 28 deg elev
09:31 - 09:45 UTC 45 deg elev
11:12 - 11:21 UTC 5 deg elev
Information on the SSTL disaster monitoring satellites is here:
http://www.sstl.co.uk/index.php?loc=120
And the UK-DMC with the Cisco Router is here:
Note, the router was not used for these tests. The code is written
directly to RTEMS on the Solid State Data Recorder Stack. Only those
portions necessary to create bundles were written into RTEMS. The
smarts where placed on the ground. All of this will eventually be
documented in a formal report and papers. This is most definitely work
in progress.
http://www.sstl.co.uk/index.php?loc=113
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/
ftp://ftp-eng.cisco.com/lwood/cleo/README.html
============================================
DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
1) Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
Station
2) Demonstrate that DTN code and general SSTL code can coexist
without effecting normal SSTL Operations
Configuration
* UK-DMC acquired a150 Mbyte image over the Gulf of Khambhat,
India at ~04:35 UTC on 25 January 2008.
* DTN bundling code default set to 80 Mbytes for proactive
fragmentation
Tests
1) Basic file download using existing technique (Saratoga)
2) Same file downloaded but treated as single bundle (DTN)
3) Same file download but using DTN proactive fragmentation with 80
Mbytes preconfigured fragments.
=============================================
Executive Summary:
The passes where successful in the fact that we learned a lot and
identified some bugs. On the surface, these bugs appear to be minor and
relatively easy to correct. Thus, for a first try, we should all be
please.
For the most part, DTN bundling and forwarding worked but we appear to
have a bug in the GRC implementation of Saratoga regarding filling holes
in missed data. In addition, there may be a bug in the DTN-2 code
implementation on the SSTL bundling agent as on bundle got stuck in a
temporary file and was never transferred from SSTL to GRC.
It appears that on the first pass, tests 1 and 2 were successful
regarding operation of DTN and the ability to either use either Saratoga
for straight file transfers or Saratoga with bundling to transfer DTN
bundles between the UK-DMC solid state data recorder and the ground.
Also the DTN-2 forwarding agent, Bundling-SSTL was able to automatically
forward the DTN bundles to a DTN-2 bundling agent at Glenn Research
Center, Bundling-GRC1. Furthermore, we could then extract the image
file from the DTN bundle.
==============================================
Detailed Analysis:
The image files for 25 January 2008 tests are available at the following
URL:
(Link Removed)
Investigation of these show each image file has "holes" in different
portions of the file.
The simplified test configuration is show in the figure below.
UK-DMC
(Bundling Only)
+------+,-.+------+
| | | |
+------+`-'+------+
.'
.'
.' Saratoga Transport
.' Over UDP
| .'
'..'
.\ `..
.i__i.
+----------+ +----------+
| Bundling | __________________________| Bundling |
| SSTL |' TCP Transport | GRC1 |
+----------+ +----------+
DTN-2-Based DTN-2-Based
Modifications
- Large files
- DTN Client to pull bundles
From UK-DMC (smarts on the ground)
Pass 1, Test 1:
The Image file DU00076pm was received using Saratoga at the
Bundling-SSTL, the DTN bundle agent at SSTL.
Pass 1, Test 2:
The DTN file and associated metadata for the full bundle was received by
Bundling-SSTL and then forwarded as a full bundle to Bundinging-GRC1
The file was then extracted from the bundle and saved as
"bundling-file".
We performed a "diff" between "saratoga-file" and "bundling-file" and
the result showed mismatch, but no detail on what was mismatched.
Post analysis showed "holes" in both the files brought down using
Saratoga for file transfer and Saratoga for bundle transfer. We suspect
a problem with the GRC implementation of Saratoga. We suspect a
problem in the perl code. This is the first place GRC will investigate
as that code is related to the hole filling. We did not really stress
the testing of that (hole filing) in the lab as we were running
error-free links. The pattern of holes in different places of each
image transfer leads us to suspect the "holes to fill" portion of the
code. That probably explains the main difference regarding file mismatch
between the first and second passes from the standpoint of that part of
the experiment. That would also explain why the Saratoga-only transfer
doesn't match the DTN one.
Pass 1, Test 3 - Proactive Fragmentation:
While running Saratoga on Bundling-SSTL we retrieved the directory and
the syslog file. The directory showed creation of the 1st fragmentation
metadata file, but not the second. We retrieved the 1st proactive
fragmented bundle from the UK-DMC and it was automatically transferred
using DTN-2 between Bundling-SSTL to Bundling-GRC1.
Upon investigation of the syslog, it appears that the 2nd metadata
proactive fragmentation metadata file was created, but the file could
not be written. Upon discussion with SSTL and investigation, it appears
the 2nd metadata file length was to be 33 characters and 32 characters
is the current limit.
* One possible way is to fix this is to recompile RTEMS such that
longer file names are allowed. Since this only effects the DTN
proactive fragmentation this may be acceptable.
* Another possible solution is to have the default file name less
than 10 characters. However, this changes SSTL's default naming system.
* A third way is to rethink how the proactive fragmentation files
are named. The long length is caused by the naming convention used
where the fragmentation metadata files and associated bundles are name
as "filename.startoffset-endoffset.dtn". Here, the start offset is the
location in memory where Saratoga should begin capturing data and the
end offset is the location where Saratoga should stop capturing data.
We will discuss possible solutions with SSTL.
Example file names:
SSTL full image = DU000c76pm
Fragment 1 (80 Mbytes) = DU000c76pm.0-79999999.dtn (25 characters)
Fragment 2 (70 Mbytes) = DU000c76pm.79999999-153700328.dtn (33
characters)
Pass 2, Test 1:
The Image file DU00076pm was received using Saratoga at the
Bundling-SSTL, the DTN bundle agent at SSTL. However, post processing
showed holes in the image file (long strings of zeros).
Pass 2, Test 2:
The DTN metadata file for the full bundle was received as was the DTN
file. However, this data was written to a temporary file and never pass
on to the DTN bundle forwarding portion of the code. Thus, the bundle
was never transferred from Bundling-SSTL to Bundinging-GRC1.
After the fact, we manually retrieved the bundle from the temporary
storage location and extracted the file. Thus, the bundle was moved
from the UK-DMC to SSTL bundling agent at the ground and then got stuck
in memory. This may take some time to troubleshoot.
Pass 2, Test 3 - Proactive Fragmentation:
While running Saratoga on Bundling-SSTL we retrieved the directory and
the syslog file. The directory showed creation of the 1st fragmentation
metadata file, but not the second. We retrieved the 1st proactive
fragmented bundle from the UK-DMC and it was automatically transferred
using DTN-2 between Bundling-SSTL to Bundling-GRC1. Thus, results were
identical to Pass1, Test 3.
Pass 3:
During the third pass of the day, GRC personnel went home to sleep and
SSTL personnel transferred the image using SSTL's version of Saratoga.
The image transferred in tact with no holes.
========================================
Next Steps to fix technical problems:
1) Induce errors into the space-to-ground and ground-to-space links
of the engineering test system and troubleshoot the "hole filling"
problem. The capability currently exists and just has to be turned on.
2) Fix the fragmentation problem associated with the long naming.
This should be relatively easy, but which approach needs to be discussed
with SSTL.
3) Analyze and investigate why the DTN bundle got trapped in
temporary storage locations on the SSTL bundle forwarding agent. This
may take some time. Our files were quite large - 150 Mbytes. This
large size may have something to do with the problem.
what is dtn?
delay/disruption tolerant network
DTN早在上个世纪就被人提出了
一开始，定位的服务就是卫星通信
后来发现太费钱，没必要，就没人搞了
现在无线领域实在是人太多，坑太少，才有被人挖出来鞭尸
也许这些测试的结果是最近做的，可是DTN用于卫星通信，这个不是创新
可以说DTN就是为了卫星通信而创立出来的概念，而且目前看来，个人观点，除了这个卫
星通信之外，还没有什么让人信服的应用场景，绝大部分都是纸上谈兵
dtn 其实更主要的应用在于深空通信，不是一般意义上的卫星通信。
受教，有相关的历史沿革的资料吗？我想看看
相关文章：
- 还有人研究卫星通信么？推荐几本入门书吧！(05-08)
- 为什么卫星通信上行频率比下行频率高？(05-08)
- 弱弱的问，卫星通信有什么新的发展么？(05-08)
- Re: 请，卫星通信，信息论高手必看！(05-08)
- 弱弱地请教一下：卫星通信的就业情况如何？(05-08)
- 五院新建了卫星通信事业部(05-08)
射频专业培训教程推荐
