wmscr rfs test for tcp/ip and ftp users - FAACO - Federal Aviation ...

existencetubNetworking and Communications

Oct 26, 2013 (3 years and 7 months ago)

184 views



Flight Service and Weather Engineering Team








Weather Message Switching Center Replacement (WMSCR)

Request for Service

TCP/IP and FTP




DRAFT







Date Published



Revision Date



Revision Number

0.1



WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
2

of
41







VERSION
NUMBER



DESCRIPTION



DATE



FAA
APPROVAL



1.0


Initial RFS Testing Requirements Document






N/A














































































WMSCR RFS


Page
3

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Table of Contents

1.0

SCOPE

4

1.1

S
COPE

4

1.2

P
URPOSE

4

1.2.1

Overview

4

1.3

I
NTRODUCTION

7

2.0

APPLICABLE DOCUMENTS

8

2.1

G
ENERAL

8

3.0

RFS TESTING

9

3.1

P
OLICY

9

3.2

R
EQUESTS

9

3.2.1

Response Times

9

3.2.2

Contact

9

3.3

P
OINTS OF
C
ONTACT

10

3.4

T
EST
R
EQUIREMENTS

10

4.0

WMSCR RFS AND USER T
ESTING REQUEST FORM

11

4.1

P
ART
1

-

R
EQUEST

11

4.2

P
ART
2

-

T
ECHNICAL
U
SER
I
NFORMATION

12

5.0

OPERATIONAL CIRCUIT
ACTIVATION AND POINT
S OF CONTACT

14

6.0

TCP/IP TESTING

15

6.1

TCP/IP

U
SER
T
EST
C
ASE
E
XAMPLES

15

6.1.1

Socket Establishment and CMHP Managem
ent Messages Processing.

16

6.1.2

WMSCR WMO Message Transmission

18

6.1.3

Subscriber WMO Message Transmission

21

6.1.4

Two Way WMO Message Transfer

24

6.1.5

Request/Reply Processing

25

6.1.6

E
rror Conditions and Node Switchover

28

6.1.7

Additional Tests

30

6.2

TCP/IP

T
EST
R
EPORT

31

7.0

FTP TESTING

32

7.1

FTP

U
SER
T
EST
C
ASE
E
XAMPLES

32

7.1.1

FTP Session Establishment and Termination

33

7.1.2

FTP User Upload Data

34

7.1.3

FTP User Download Data.

37

7.1.4

Error Conditions and FTP Server Switchover

38

7.1.5

FTP Additional Tests

39

7.2

FTP

T
EST
R
EPORT

40

8.0

WMSCR DATABASE CHANG
E REQUEST

41


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
4

of
41






1.0

SCOPE


1.1

Scope

This document establishes the requirements for the Weather Message Switching Center
Replacement (WMSCR) Request for Service (RFS)

Testing. WMSCR is part of the Federal
Aviation Administration's (FAA) National Airspace System (NAS). WMSCR has been
promulgated by NAS
-
DD
-
1000, NAS
-
SS
-
100000 Volume II, and FAA Order 7032.3.


1.2

Purpose

The purpose of this document is to provide new TCP/I
P and FTP users with the information that
they need to be able to request time and resources, as necessary, in the testing of their systems
with WMSCR. WMSCR RFS testing is a one
-
sided look from a WMSCR perspective of how a
new user will perform in conjun
ction with the existing WMSCR field environment
.


This document also contains the RFS Test Report and Database Change Request Form.
Combined, these forms and tables will provide all of the data necessary to allow a subscriber to
become an active WMSCR subs
criber. An updated copy of this document, containing all
required test information will be maintained in WMSCR documentation archives.

1.2.1

Overview

WMSCR is an operational FAA NAS subsystem that receives, processes, and stores
alphanumeric aviation weather p
roducts and disseminates these products to a variety of NAS and
non
-
NAS users. WMSCR is a principal gateway to the National Weather Service (NWS) and the
military and foreign countries for the exchange of alphanumeric weather data. WMSCR is the
central hub

system for the distribution of aviation weather and Notices to Airmen (NOTAM)
messages to users in the FAA. Additionally, it is the FAA distribution system for NOTAMs from
the US NOTAM System Replacement (USNSR). WMSCR provides weather products and
NOTAM
messages to traffic management specialists and Center Weather Service Unit (CWSU);
meteorologists through the Aeronautical Information System Replacement (AIS
-
R); and to air
traffic controllers through the HOST. Similarly, WMSCR provides weather products
and
NOTAMs to air traffic control specialists through the AIS
-
R, the Aviation Weather Processor
(AWP), and the Flight Service Data Processing System (FSDPS). Many users outside the FAA
are dependent on WMSCR for these products. Included are dispatchers a
nd meteorologists at
Airline Operations Centers, commercial pilots through Aeronautical Radio Incorporated
(ARINC), meteorologists at the NWS’ Aviation Weather Center, and General Aviation pilots
through the Direct User Access Terminal (DUAT) service.

Th
is document describes the interface testing between WMSCR and those user systems that need
to send or receive WMO
-
formatted weather products via TCP/IP or FTP. These services require
that both WMSCR and the users communicate via the FTI IP network as depic
ted in
Figure 3
-
1
.

WMSCR RFS


Page
5

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc


Figure 3
-
1
. WMSCR Interface Connections with FTI

FTI is the FAA’s US
-
wide operational IP network that has points of presence at predominantly
FAA facilities. Acce
ss by non
-
NAS systems to this network will be via FTI Gateways that
provides additional levels of security. (See the FTI User’s Guide for further information.)

The two WMSCR systems are located at the National Network Control Centers (NNCCs)
located in Atl
anta GA. (ATL) and Salt Lake City UT. (SLC) and operate in a primary/secondary
relationship. Only the WMSCR System that is operating as the primary system is able to support
client systems. The secondary system operates as a hot standby and can be switche
d into a
primary role at any time.


WMSCR also supports client systems that need to send or receive WMO
-
formatted weather
products via FTP. Two FTP Servers will be operational and clients are “load
-
shared” between
the two. Each FTP Client will be instructe
d to use a specific site’s FTP Server as its preferential
choice, the other as a backup.


This FTP
-
based service requires that both WMSCR FTP Server and the FTP clients
communicate over the FTI IP network as depicted in Figure 3
-
2.


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
6

of
41






Figure
1
-
2. WMSCR Interface Connections with Demarcation Points


WMSCR RFS


Page
7

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

1.3

Introduction

This document provides requirements that must be met in order to ensure that live connectivity
to the WMSCR system can be accomplished without the inje
ction of system problems. To that
end, a Request for Service (RFS) must undergo a series of tests that identify areas that can be a
problem, or present a problem, to the WMSCR system.


Section 1 includes the identification of this document, the purpose of

WMSCR, and the
Introduction to this document.


Section 2 lists other documents applicable to WMSCR requirements to the extent described in
this specification.


Section 3 contains general information on policy, requests, Point of Contacts, performance,
int
erfaces, requirements, and forms.


Section 4 contains RFS and User Request forms.


Section 5 contains Points of Contact.


Section 6 contains TCP/IP Test examples and sample Test Report Form


Section 7 contains FTP examples and sample Test Report Form


Sect
ion 8 contains a WMSCR Database Change Request Form


Note: Items shown in
Blue

text will be used to generate the Database Change Request after
testing is complete.


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
8

of
41





2.0

Applicable Documents


2.1

General

The documents listed below form a part of this specification
and are applicable to the extent
described in this document.

FAA
-
X
-
XXXX

November 15, 1999

FAA Telecommunications Infrastructure (FTI) Telecommunications
Services Description



FAA
-
XXX
-
xxx

March 2007 (Draft)

FTI Operational IP User Guide



NAS
-
IC
-
xxxx.


May 2007 (Draft)

WMSCR ICD for TCP/IP Services using CMHP



NAS
-
IC
-
xxxxx

May 2007 (Draft)

WMSCR ICD for FTP Services.



T.B.D.

WMSCR Weather Data Sheets Document



IETF RFC 959

October 1985

File Transfer Protocol (FTP)



WMO 386

2004

World Mete
orological Organization, Manual on Telecommunications




WMSCR RFS


Page
9

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

3.0


RFS Testing

3.1

Policy

It is the policy of the WMSCR Product Team that no supplier of weather information may
request or specify that their products be distributed to another user’s circuit. The dat
a distributed
to WMSCR users is requested by that user and may only be changed by the recipient of the data.
Requests for changes to distribution on live WMSCR circuits shall be sent through the National
Network Control Center (NNCC) Communication Special
ist at Atlanta, GA or Salt Lake City,
UT WMSCR.

3.2

Requests

WMSCR RFS testing is performed as a Flight Service and Weather Engineering Team field
support function for the WMSCR Atlanta (ATL) and WMSCR Salt Lake City (SLC) National
Network Control Center (NNCC
) field sites. WMSCR TCP/IP or FTP RFS testing is performed
for new WMSCR TCP/IP or FTP users prior to user connecting a system to a live WMSCR site
using these services. Section 4 contains the WMSCR Request for Service (RFS) and User
Testing forms. If

your system requires multiple WMSCR connections, additional copies of the
Part Two Addendum will need to be filled out.

3.2.1

Response Times

The request for service should be placed three (1
-
3) months prior to anticipated test dates. The
Flight Service and Wea
ther Engineering Team will reply within two (2) weeks of the request.
Testing results are good for eight (8) weeks after testing prior to going operational. A WMSCR
database and configuration update is required in order to add a new user to the WMSCR syst
em.
New users will be added during scheduled 56 day updates only.

3.2.2

Contact

The Flight Service and Weather Engineering Team will maintain communication with the
operational sites and verify that valid contact information for WMSCR users is updated in the
Fl
ight Service and Weather Engineering Team records once a year.


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
10

of
41





3.3

Points of Contact

FAA

ATTN: Cathy Krupa

Mailstop: AJW
-
176

William J. Hughes Technical Center

Atlantic City International Airport

Atlantic City, NJ 08405

(609) 485
-
4544

3.4

Test Requirements

WMSCR

RFS testing is a one
-
sided look, from a WMSCR perspective, of how a new user will
perform in conjunction with the existing WMSCR field environment. It is not a test of the
WMSCR system or the FTI Network. FTI RFS testing must be completed prior to WMSCR
RFS
testing. WMSCR RFS testing is not a substitute, replacement, or augmentation for any testing
that should be completed successfully (ex, OT&E and SAT testing), with no major deficiencies,
prior to RFS testing with WMSCR. The WMSCR personnel at the Tech
nical Center will report
the results of this RFS testing to the live WMSCR field facilities so that the WMSCR field sites
can determine if the new user is ready for live connectivity to the WMSCR system. Final
authorization for connection to the live WMSC
R is determined by the National Network
Communications Centers (NNCCs) in Atlanta, GA or Salt Lake City, UT.


After the successful completion of WMSCR RFS testing, it is expected that the new user will be
loading the same RFS tested version of software ont
o their first live site in the field. Therefore,
the user should “freeze” this tested baseline so it can be loaded at the field site. Future software
loads do not have to be retested by WMSCR unless additional WMSCR functionality is
incorporated into the

software (ex, now utilizing the Request/Reply function) or a change is
made to the user’s communication software that could impact data transmissions.

WMSCR RFS testing should be successfully completed several weeks prior to requesting
connectivity to the

live WMSCR system.


WMSCR RFS


Page
11

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

4.0


WMSCR RFS and User Testing Request Form

4.1

Part 1
-

Request

WMSCR Request For Service & User Testing

Part 1
-

General User Information


1.) Date of Request:


2.) Estimated Date of Service:


3.) Organization Name:


4.) Estimated Test D
ate:


5.) Phone:



6.) FAX:


7.) E
-
mail/Internet Address:


8.) Company Address:


9.) Pre
-
Connection Point(s) of Contact: (Name and phone numbers of individuals responsible for
coordination of this service connection request. For multiple points of conta
ct, please provide a
complete list).





10.) Post
-
Connection Point(s) of Contact: (Names and phone numbers of individuals responsible for
post
-
connection activities, including maintenance, repair, and trouble reporting. Please provide
multiple points of
contact, if available. MUST Be reachable 24 Hours x 7 Days).





11.) Please indicate if you have a completed Memorandum Of Agreement (MOA) with the Federal
Aviation Administration (FAA). If completed, please attach a copy to this RFS.



WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
12

of
41





4.2

Part 2
-

Technic
al User Information

WMSCR Request For Service & User Testing

Part 2
-

Technical User Information


*Only fill this form out one time.



1)

Location: (City, state, province, and country where service is requested).



2)

Estimated Date of FTI RFS Test Completion:


3)

IP Test Addr
ess(es).


4)

End State IP Adress(es)


5)

Type of Service (FTP or TCP/IP):

6)

User Type (NAS or non NAS).

Note: The type of FTP service required (SFTP, FTP) may be dependant on user type

7)

Present Source of weather data: (if applicable, please list any sources you

presently utilize for
weather data).


8)

Present Source of Notice to Airmen (NOTAM) data: (if applicable, please list any source you
presently utilize for NOTAM data).


9)

Present Source of military weather data: (if applicable, please list any source you pre
sently
utilize for military weather data).


10)

TCP/IP Users Only
-

Please indicate if your application processes the message formats as
specified in Appendix 10 and Appendix 20 of
Interface Control Document
Weather Message
Switching Center Replacement (WMSC
R) TCP/IP Services

: (Required Messages are shown in
bold)


Message Type

Processed Y/N

Registration Request

/Registration Response


Stop Service Notification/Stop Service Response


Acknowledgement Message


WMO Message


inbound to WMSCR


WMO Message


o
utbound from WMSCR


WMSCR RFS


Page
13

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

WMO Request Messages (
Note: WMSCR does not process request/replies from
H+55 till the top of hour.).


Request Type

Used Y/N

W(MO)


RE(PORT)


RQ


RC


RL



A d d i t i o n a l N o t e s/E x c e p t i o n s:


1 1 )

FTP Users

=
m汥lse⁩湤=ca瑥⁴桡琠y潵爠o灰汩
ca瑩潮⁦o汬潷猠瑨攠o楬e=浩湧=a湤⁦n牭r瑴楮i=
c潮癥湴n潮猠獰散楦楥搠楮d䅰灥湤楸‱〠潦⁴桥⁗MpCo⁆呐=fC䐠a湤⁩摥湴nfy=any⁥xce灴p潮猺
=
FTP File Conventions

Comply
Y/N

File Naming


File Format



Additional Notes/Exceptions:


10.)All
-

Please indicate if
your application transmits weather data to WMSCR: (All data transmitted
into WMSCR is in accordance with the Manual on the Global Telecommunications System (WMO
-

386)).

Please provide the following information for each WMO header (Add additional sheets as

necessary)

WMO HEADER

Data Type

Reporting Station(s)

Frequency/Size

























Additional Notes:


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
14

of
41





5.0

Operational Circuit Activation and Points of Contact



WMSCR Operational Circuit Activation & Points of Contact


The following informat
ion describes the general process of obtaining a connection to WMSCR.


1.) I DONT KNOW ABOUT ANY OF THIS!

After the testing is completed, the Flight Service and Weather Engineering Team will incorporate
the FTI User data into a future, scheduled field dat
abase release. The Flight Service and Weather
Engineering Team will notify the FTI User of their assigned WMSCR site upon completion of the
database install.


2.) The FTI user will verify their FTI connectivity. Note* Circuit/port will not be placed i
n
service until coordinated with FTI and WMSCR at the respective sites. * This process has not
been defined TBD.



3.) Coordination and activation of the circuit will be accomplished by the FTI Users primary
WMSCR node and FTI. This process has not been d
efined TBD.



POINTS OF CONTACT (ATLANTA)

POINTS OF CONTACT (SALT LAKE CITY)


WMSCR NODE: 1
-
770
-
210
-
7931


FTI
-

TBD


MANAGER OF TECHNICAL
OPERATIONS: 1
-
770
-
210
-
7718


SUPERVISOR OF WEATHER UNIT:

1
-
770
-
210
-
7680


NOTE: (WMSCR should be contacted for
weat
her/NOTAM and other related WMSCR
issues.

FTI should be contacted for communication
issues. Manager/supervisor numbers are
provided for informational purposes.)



WMSCR NODE: 1
-
801
-
320
-
2039


FTI
-
TBD


MANAGER OF TECHNICAL OPERATIONS:

1
-
801
-
320
-
2165


SUPE
RVISOR OF WEATHER UNIT:

1
-
801
-
320
-
2169



NOTE: (WMSCR should be contacted for
weather/NOTAM and other related WMSCR
issues.

FTIshould be contacted for line/modem issues.
Manager/supervisor numbers are provided for
informational purposes.)

WMSCR RFS


Page
15

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

6.0

TCP/IP Testin
g


This section conatins test case examples and the RFS test report generated at the completion of
testing. The test case examples show the extent of the test effort and familiarize the requestor
with the verification parameters expected. Additional test m
ay be performed as requested by
either the subscriber or the WMSCR personnel.


Prior to RFS testing the following information should be negotiated between WMSCR and the
Subscriber.


WMSCR Test Engineer should record these values prior to or at the time of
the test.

Socket Initiator_____________________

Subscriber Identification Field 1 _________________

Subscriber Identification Field 2__________________

Registration Timeout Value ________

Inactivity Timeout Value ________

Number of Unacknowledged Messages
Allowed (Outbound from WMSCR). _______

Number of Unacknowledged Messages Allowed (Inbound to WMSCR). _______


6.1

TCP/IP User Test Case Examples


Not all test cases apply to each subscriber system. Prior to RFS testing, the cases to be executed
should be negot
iated between WMSCR and the subscribing system and should be indicated in
the following table.

Test Case

Required

Y/N

6.1.1 Socket Establishment and CMHP Management Messages Processing.

Y

6.1.2 WMSCR WMO Message Transmission


6.1.3 Subscriber WMO Messag
e Transmission


6.1.4 Two Way WMO Message Transfer


6.1.5 Request/Reply Processing


6.1.6 Error Conditions and Node Switchover

Y

6.1.7 Additional Tests




WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
16

of
41






6.1.1

Socket Establishment and CMHP Management Messages Processing.


This test case will verify that
TCP/IP Users can connect to the Atlantic City WMSCR node and
process CMHP Management Messages in accordance with the WMSCR TCP/IP Users ICD.


Step #

Action:

Result:

Pass/Fail:


1.


Activate the circuit via the
ACYCM WMSCR node main
menu.

Using SCF on the WMS
CR
system verify the socket
connection has been established.


2.


Wait for receipt of a Registration
Request message..

Verify that a valid Registration
Request is received from the
subscriber within the configured
timeout time.


Verify the Registration Reque
st is
formatted in accordance with the
WMSCR TCP/IP ICD. (Check
M(S) and M(R) and verify they
have been reset to 0)


The status in the Circuit Monitor
screen on ACYCM will show
“CONNECTED” for the circuit
畮摥爠瑥獴⸠s
=
=



With the idle timer on the
WMSCR s
ystem set to a smaller
value than the subscriber system
wait for idle timer expiration and
the transmission of an
Acknowledgement message to the
subscriber system..

Verify an Acknowledgment
message is received back from the
subscriber system.


Verify the
Acknowledgement
message is formatted in
accordance with the WMSCR
TCP/IP ICD..


Verify the Final bit is set.


WMSCR RFS


Page
17

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

4.


With the idle timer on the
WMSCR system set to a larger
value than the subscriber system
wait for the subscriber system’s
楤ie⁴=浥m⁥x灩牡瑩潮o
=
乏呅㨠ft⁷楬=⁢==ce獳sry⁴漠
浯摩fy⁴桥⁩湩⁦楬eⰠIe獴慲琠t桥=
c楲i畩u⁩湴e牦ace⁰牯ce獳sa湤n
牥e獴慢汩s栠瑨攠h楲c畩u⁣o湮nc瑩潮o
楮牤i爠瑯⁰rr景f洠m桩猠he獴
=
噥物ry⁡渠䅣歮潷汥dgme湴n
浥獳m来⁩猠牥ce楶敤⁦牯r⁴桥=
獵扳捲楢敲⁳y獴敭⸠
=
=
噥物ry⁴桥⁁c歮潷汥d来
浥湴m
浥獳m来⁩猠景=浡瑴敤⁩渠
acc潲oa湣e⁷楴栠=桥⁗䵓Co=
呃qLfm=fC䐮a
=
=
Verify the Poll bit is set”.
=
=



Subscriber system performs
graceful termination of
connection.

Verify a Stop Service Notification
message is received from the
subscriber system.


Verify
the Stop Service
Notification message is formatted
in accordance with the WMSCR
TCP/IP ICD.


After the Stop Service Response is
sent by WMSCR, use SCF to
verify the socket connection is
closed.



6.


WMSCR performs graceful
termination of connection.

After t
he Stop Service Notification
message is transmitted from
WMSCR, verify a Stop Service
Response message is received
from the subscriber system.


Verify the Stop Service Response
message is formatted in
accordance with the WMSCR
TCP/IP ICD.


After the Stop
Service Response is
received by WMSCR, use SCF to
verify the socket connection is
closed.





WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
18

of
41





6.1.2


WMSCR WMO Message Transmission


This case will verify the subscriber system can receive WMO data from the Atlantic City
WMSCR node in accordance with Appendix 2
0 of the WMSCR TCP/IP ICD.


Step #

Action:

Result:

Pass/Fail:


1.

.

Establish the connection between
the WMSCR system and the
subscriber.


The socket will be established as
negotiated, and the subscriber
system will send a valid
Registration Request message
.


The status in the Circuit Monitor
screen will state “CONNECTED”
景f⁴桥⁣楲c畩u⁵湤=爠瑥獴s
=
=
=


.

Configure the WMSCR message
distribution to send data to the
subscriber system.

WMO data should be transmitted
WMSCR and be received by the
user.


3.


Wait un
til the configured
maximum number of
unacknowledged messages have
been transmitted.

Verify an Acknowledgement
message is received from the
subscriber system.


Verify the Acknowledgement
message is formatted in accordance
with Appendix 10 of the WMSCR
TCP/I
P ICD.


Verify the appropriate M(S) and
M(R) values are included in the
message.


4.


Repeat step 3 as needed to verify
correct usage of M(S) and M(R)
fields.

Verify an Acknowledgement
message is received from the
subscriber system.


Verify the Acknowledgeme
nt
message is formatted in accordance
with Appendix 10 of the WMSCR
TCP/IP ICD.


Verify the appropriate M(S) and
M(R) values are included in the
message.


WMSCR RFS


Page
19

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

5.


Disable output on the WMSCR
system and wait for the idle timer
to elapse.

Verify the Acknowledgemen
t
message is formatted in accordance
with Appendix 10 of the WMSCR
TCP/IP ICD.


Verify the appropriate M(S) and
M(R) values are included in the
message


6.


Enable output on the WMSCR
system and wait until the
configured maximum number of
unacknowledged mess
ages have
been transmitted.

Verify an Acknowledgement
message is received from the
subscriber system.


Verify the Acknowledgement
message is formatted in accordance
with Appendix 10 of the WMSCR
TCP/IP ICD.


Verify the appropriate M(S) and
M(R) values are

included in the
message.


7.


Disconnect/Reconnect the
subscriber system

Verify the Registration Request
sent by the subscriber has the M(S)
and M(R) fields reset.


8.


Enable output on the WMSCR
system and wait until the
configured maximum number of
unacknow
ledged messages have
been transmitted.

Verify an Acknowledgement
message is received from the
subscriber system.


Verify the Acknowledgement
message is formatted in accordance
with Appendix 10 of the WMSCR
TCP/IP ICD.


Verify the appropriate M(S) and
M(R)

values are included in the
message.


9.


From the WMSCR system, force
the transmission (HOW?) of a
WMO message with the final bit
set.

Verify an Acknowledgement
message is received from the
subscriber system.


Verify the Acknowledgement
message is formatted

in accordance
with Appendix 10 of the WMSCR
TCP/IP ICD.


Verify the appropriate M(S) and


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
20

of
41





M(R) values are included in the
message.

WMSCR RFS


Page
21

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

6.1.3

Subscriber WMO Message Transmission


This case will verify the subscriber system can send WMO data to the Atlantic City WM
SCR
node in accordance with Appendix 20 of the WMSCR TCP/IP ICD.


Step #

Action:

Result:

Pass/Fail:


1.

.

Establish the connection between
the WMSCR system and the
subscriber.


The socket will be established as
negotiated, and the subscriber
system will sen
d a valid
Registration Request message.


The status in the Circuit Monitor
screen will state “CONNECTED”
景f⁴桥⁣楲c畩u⁵湤=爠瑥獴s
=
=
=



On the WMSCR system,
configure the circuit to enable
input.

WMO data should be transmitted
by the subscriber and be rec
eived
by the WMSCR system.


Verify the WMO data is formatted
in accordance with Appendix 20 of
the WMSCR TCP/IP ICD.


Verify the M(S) and M(R) fields of
the data mesage


3.



Verify that each line of the report
shall be no more than 69 characters,
including
control characters CR,
CR, LF and shall be broken up on a
word boundary. If a METAR or a
SPECI exceeds one line, the
succeeding lines are indented five
spaces..


4.



All reports contained under a WMO
heading shall end in an equal sign.
Within the text of
a message, each
individual meteorological report
shall start at the beginning of a new
line.


5.



Each WMO header shall be
checked to verify that the TTAAii
are valid for the report type and
reporting location in the report. In
other words, if the WMO head
er is


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
22

of
41





UAUS01 KZTL, then the report
type is UUA and the reporting
location is checked to make sure it
is a valid reporting location.

6.



If a WMO header “TTAAii CCCC
DDHHMM” is used more than
潮oeⰠ瑨敮⁴桥=BBB=晩f汤la猠
摥獣物扥搠楮⁗䵏
-
㌸㘬P獥c瑩潮o
㈮㌮O
⸲.

=
灡来⁁⸱=
-

-
=
u湤n爠剒xⰠ
CCxⰠI湤⁁nx⁷桥牥⁸⁩猠s渠
a汰桡扥瑩c⁣ha牡c瑥t=景f=䄠瑨A潵o栠
堬畳u⁢=⁩=灬敭p湴敤n
=
=




The date/time field in the WMO
header DDHHMM shall be valid
for each DATE/TIME contained in
the individual reports. Also, each
report c
ontained within the WMO
product shall be checked to verify
that it has a correct date/time field.


8.



Verify that each WMO header is
followed by a valid text portion.


9.



When multiple reports with WMO
headers are entered, each report
should be separated b
y =” and each
癡汩摡瑥搠t湤⁴牡湳浩瑴ed⁡猠
獥灡牡te⁲=灯牴献†周r獥⁲e灯牴猠
浵獴⁢=映瑨=⁳=浥⁴y灥=⡥x⸠啁⤮F
=
=
㄰N



All reporting locations and data
types contained in the text should
be checked to make sure they are
valid. Note some reports have three
ch
aracter reporting locations, i.e.,
UAs and UUAs etc…and some
have four, i.e., CWAs…etc.
=
=
ㄱN


.

All text data contained in a report
should be checked to ensure that it
only contains uppercase letters,
printable characters, and the CR,
CR, LF


12.



Each product
should have a valid
time on the queue to WMSCR. This
time is presently MIS products (3
hours), CWA products (2 hours),

WMSCR RFS


Page
23

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

and UA and UUA products (1
hour). If WARP or WMSCR lose
connectivity for over one hour,
products with an invalid date/time
should be pur
ged off the WMSCR
queue and not sent. Sending in of
products with an invalid date/time
will cause the WMSCR edit queue
to fill with messages that need to be
discarded.


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
24

of
41





6.1.4

Two Way WMO Message Transfer


This case will verify the subscriber system can send a
nd receiveWMO data to the Atlantic City
WMSCR node simultaneously, in accordance with Appendix 20 of the WMSCR TCP/IP ICD.


Step #

Action:

Result:

Pass/Fail:


1.

.

Establish the connection between
the WMSCR system and the
subscriber.


The socket will be est
ablished as
negotiated, and the subscriber
system will send a valid
Registration Request message.


The status in the Circuit Monitor
screen will state “CONNECTED”
景f⁴桥⁣楲c畩u⁵湤=爠瑥獴s
=
=
=


.

On the WMSCR system,
configure the circuit to enable
input.

WMO data should be transmitted
by the subscriber and be received
by the WMSCR system.


Verify the WMO data is formatted
in accordance with Appendix 20 of
the WMSCR TCP/IP ICD.


Verify the M(S) and M(R) fields of
the data mesage


3.


Disconnect/Reconnect the
subscriber system

Verify the Registration Request
sent by the subscriber has the M(S)
and M(R) fields reset.


WMSCR RFS


Page
25

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

6.1.5


Request/Reply Processing


This test case will verify the subscriber can request data from the Atlantic City WMSCR node
and process either the
response sent from the Atlantic City WMSCR node in accordance with the
Appendix 20 of the WMSCR TCP/IP ICD. WMSCR does not process request/replies from
H+55 till the top of hour. *


NOTE: Users must NOT automate any request/reply functions to WMSCR. User
s should be
aware that automating their request/replies could result in termination of their request/reply
functions from the WMSCR field sites.


When WMSCR receives a valid request for a product that is currently available in the WMSR
database, the respon
se message returned to the subscriber contains the WMO data for the
requested product(s). However; not all products, especially unscheduled products, are always
available in the WMSCR database. Response messages which indicate an unavailability of data
o
r an error in the request message can be configured for each request type. The following
information needs to be obtained and configured in the WMSCR system prior to execution of
this test.

Response Configuration

Request Type

Response

select from list be
low

LIST

Partial Data


No Data


Invalid Command


RC

Partial Data


No Data


Invalid Command


RE(PORT)

Partial Data


No Data


Invalid Command


RL

Partial Data


No Data


Invalid Command


RQ

Partial Data


No Data


Invalid Command


WM
O

Partial Data


No Data


Invalid Command



The following responses may be issued for valid Requests when some or all of the data is not
available in the WMSCR system:


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
26

of
41





A.

Do not Send a Response


No response is returned from the WMSCR system. The
request
or portion of request is ignored.

B.

Send NIL


A response containing “NIL” is sent for the request or each portion of the
request for which there is no data available.

C.

Send No Report Available


A response message is returned from the WMSCR
containing “No Re
port Available” for the request or portion of the request for which there
is no data available.

D.

Send No Report Available echo


A response message is returned from the WMSCR
containing “No Report Available” for the request or portion of the request for whi
ch there
is no data available. The input request data is also echoed back in the response message


The following responses may be issued for Request messages which are not formatted properly
or the requested product is not adapted in the WMSCR database.

A.

Do

not Send a Response


No response is returned from the WMSCR system. The
request or portion of request is ignored.

B.

Not in System


The WMSCR system returns a response containing “Not In System”.

C.

Not in System echo


The WMSCR system returns a response con
taining “Not In
System” and echoes the input request text.

WMSCR RFS


Page
27

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc


Step #

Action:

Result:

Pass/Fail:


1.


Establish the connection between
the WMSCR system and the
subscriber.


The socket will be established as
negotiated, and the subscriber
system will send a val
id
Registration Request message.


The status in the Circuit Monitor
screen will state “CONNECTED”
景f⁴桥⁣楲c畩u⁵湤=爠瑥獴s
=
=
=



Configure the WMSCR system to
enable request/reply for the
subscriber system.


N/A

3.


The subscriber should send each
of the re
quest types indicated in
the RFS form and also include the
following as applicable:

Invalid report types,

Invalid station id,

Invalid WMO headers.

Verify the request message are
formatted in accordance to
Appendix 20 of the WMSCR
TCP/IP ICD.


4.



Verify t
hat the user has NOT
automated any request/reply
functionality. Users will be
notified that automating their
request/replies could result in
termination of their request/reply
functions from the WMSCR field
sites.



WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
28

of
41





6.1.6

Error Conditions and Node Switchover

T
his test case will verify the subscriber system can handle some common interface errors and
can connect to the alternate WMSCR node during a node switchover.


Step #

Action:

Result:

Pass/Fail:


1.


In WMSCR, configure the
subscriber system using
incorrect

su
bscriber information.

Note: It will necessary to restart
the associated circuit interface
process.


Activate the circuit via the
ACYCM WMSCR node main
menu.

Using SCF on the WMSCR system
verify the socket connection has
been established.


The socket will b
e established as
negotiated, and the subscriber
system will send a valid
Registration Request message.


The status in the Circuit Monitor
screen will state
“DISCONNECTED” for the circuit
under test



2.


In WMSCR, correct the
configuration data.


Activate th
e circuit via the
ACYCM WMSCR node main
menu


Using SCF on the WMSCR system
verify the socket connection has
been established.


The socket will be established as
negotiated, and the subscriber
system will send a valid
Registration Request message.


The sta
tus in the Circuit Monitor
screen will state “CONNECTED”
for the circuit under test


3.


From the WMSCR system
generate an unexpected Stop
Service Message (How? TBD)

Verify the subscriber system sends
a Stop Service Response message
and verify the socket con
nection is
terminated.


WMSCR RFS


Page
29

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

4.


Activate the circuit via the
ACYCM WMSCR node main
menu


Using SCF on the WMSCR system
verify the socket connection has
been established.


The socket will be established as
negotiated, and the subscriber
system will send a valid
R
egistration Request message.


The status in the Circuit Monitor
screen will state “CONNECTED”
景f⁴桥⁣楲c畩u⁵湤=爠瑥獴
=
=



On the WMSCR system, perform
an orderly node switchover to the
ACY node.

Using SCF on the WMSCR system
verify the socket connection
on the
ACYCM system has been
terminated.


Using SCF on the WMSCR system
verify the socket connection on the
ACY system has been established.


The socket will be established as
negotiated, and the subscriber
system will send a valid
Registration Request mes
sage.


The status in the Circuit Monitor
screen will state “CONNECTED”
景f⁴桥⁣楲c畩u⁵湤=爠瑥獴
=
=



Initiate data transfer as applicable

Verify the subscriber can send and
receive data as needed.



WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
30

of
41





7.


On the WMSCR system, perform
an orderly node switchover
to the
ACYCM node.

Using SCF on the WMSCR system
verify the socket connection on the
ACY system has been terminated.


Using SCF on the WMSCR system
verify the socket connection on the
ACYCM system has been
established.


The socket will be established as
ne
gotiated, and the subscriber
system will send a valid
Registration Request message.


The status in the Circuit Monitor
screen will state “CONNECTED”
景f⁴桥⁣楲c畩u⁵湤=爠瑥獴
=
=
6.1.7

Additional Tests

Add any additional tests requested by either WMSCR or the sub
scriber system to this section.


Step #

Action:

Result:

Pass/Fail:


1.





2.





3.





4.





5.





6.







WMSCR RFS


Page
31

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

6.2

TCP/IP Test Report

WMSCR TCP/IP RFS Test Report

Subscriber System: _____________________

Date: ______________________

WMSCR Test Engineer(s): _________
_____________ Phone:_________________


_______________________ __________________

Subscriber Test Engineer(s): ____________________ Phone: _________________



_______________________ __________________


Test Case

Pass/Fail

Notes

5.1.1 Socket Establishment and CMHP
Management Messages Processing.



5.1.2 WMSCR WMO Message Transmission



5.1.3 Subscriber WMO Message Transmission



5.1.4
Two Way WMO Message Transfer



5.1.5 Request/Reply Processing



5.1.6 Error Conditions and Node Switchover



5.1.7 Additional Tests




Additional Information:


Reccommendation:




Final Disposition:




__________________________________

________________________

WMSCR Test Engineer Date


WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
32

of
41





7.0


FTP Testing


This section contains test case examples for FTP users and the RFS test report generated at the
completion of testing. The t
est case examples show the extent of the test effort and familiarize
the requestor with the verification parameters expected. Additional test may be performed as
requested by either the subscriber or the WMSCR personnel.


Prior to RFS testing the following

information should be negotiated between WMSCR and the
Subscriber.


WMSCR Test Engineer should record these values prior to or at the time of the test.

FTP Client Logon ID _________________

FTP Client Password__________________

Inactivity Timeout Value __
______

Assigned FTP Ingest Directory _______________________________________

NASAO ONLY


FTP Ingest Directory for Raw Data _______________________________



7.1

FTP User Test Case Examples


Not all test cases apply to each subscriber system. Prior to RFS tes
ting, the cases to be executed
should be negotiated between WMSCR and the subscribing system and should be indicated in
the following table.

Test Case

Required

Y/N

7.1.1 FTP Session Establishment.

Y

7.1.2 FTP User Upload Data


7.1.3 FTP User Download Da
ta


7.1.4 Error Conditions and FTP Server Switchover

Y

7.1.5 Additional Tests



WMSCR RFS


Page
33

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc


7.1.1

FTP Session Establishment and Termination


This test case will verify that FTP users can connect to the Atlantic City WMSCR FTP server.


Step #

Action:

Result:

Pass/Fail:


1.


Establish the connection between
the WMSCR FTP server and the
client


The FTP client will establish a
socekt connection to the WMSCR
FTP server and perform the logon
sequence as defined in the FTP
RFCs.


The the WMSCR FTP server
shows a status of “Conn
ected” for
瑨攠t呐⁣汩e湴⁵湤敲⁴e獴s
=
=



The FTP client should gracefully
terminate the FTP session.

The FTP session should be
terminated as defined in the FTP
RFCs.


The the WMSCR FTP server
shows a status of “Discconnected”
景f⁴桥⁆呐⁣汩e湴⁵湤敲⁴e獴
=
=



Establish the connection between
the WMSCR FTP server and the
client


The FTP client will establish a
socekt connection to the WMSCR
FTP server and perform the logon
sequence as defined in the FTP
RFCs.


The the WMSCR FTP server
shows a status of “Con
nected” for
瑨攠t呐⁣汩e湴⁵湤敲⁴e獴s
=
=



Wait for the FTP inactivity timer
to expire.

The WMSCR FTP Server will
terminate the FTP session. Verify
the socket connection is closed.




WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
34

of
41






7.1.2

FTP User Upload Data


This test case will verify that FTP users place
properly formatted data files on the WMSCR FTP
server.


Step #

Action:

Result:

Pass/Fail:


1.


Establish the connection between
the WMSCR FTP server and the
client


The socket will be established as
negotiated, and the FTP client will
logon to the WMSCR FTP
server..


The the WMSCR FTP server
shows a status of “Connected” for
瑨攠t呐⁣汩e湴⁵湤敲⁴e獴s
=
=



The FTP client should initiate a
file transfer to the WMSCR FTP
server.

Data files containing WMO data
should be transmitted by the
subscriber and be receiv
ed by the
WMSCR system.



3.



Verify the files are non
-
zero length
and are placed in the assigned
ingest directory.



4.



Verify the file name is formatted
according to the conventions
described in Section A.ii
-
15/32 of
WMO 386.


5.



Verify the first line of

the file
contains the WMO Bulletin
Separator Line in accordance with
Appendix 10 of the WMSCR FTP
ICD.


If multiple WMO bulletins are
contained in the file, verify a
separator line precedes each
additional bulletin.


6.



Verify the WMO data is formatted
i
n accordance with Appendix 10 of
the WMSCR FTP ICD.



WMSCR RFS


Page
35

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

7.



Each WMO header shall be
checked to verify that the TTAAii
are valid for the report type and
reporting location in the report. In
other words, if the WMO header is
UAUS01 KZTL, then the report
type
is UUA and the reporting
location is checked to make sure it
is a valid reporting location.


8.



The date/time field in the WMO
header DDHHMM shall be valid
for each DATE/TIME contained in
the individual reports. Also, each
report contained within the WMO

product shall be checked to verify
that it has a correct date/time field


9.



Verify that each line of the report
shall be no more than 69
characters, including control
characters CR, CR, LF and shall
be broken up on a word boundary.
If a METAR or a SPECI

exceeds
one line, the succeeding lines are
indented five spaces.


10.



All reports contained under a
WMO heading shall end in an
equal sign. Within the text of a
message, each individual
meteorological report shall start at
the beginning of a new line.


11.



Verify all WMO messages contain
a text portion consisting of valid
data.


12.



When multiple reports with WMO
headers are entered, each report
should be separated by =” and
eac栠ha汩摡瑥搠t湤⁴na湳浩瑴e搠d猠
獥灡牡te⁲=灯牴献†周r獥⁲e灯牴猠
浵獴⁢=映瑨=⁳=
浥⁴y灥=⡥x⸠啁⤮
=
=

WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
36

of
41





13.



All reporting locations and data
types contained in the text should
be checked to make sure they are
valid. Note some reports have
three character reporting locations,
i.e., UAs and UUAs etc…and
some have four, i.e., CWAs…etc.
=
=
ㄴN



Al
l text data contained in a report
should be checked to ensure that it
only contains uppercase letters,
printable characters, and the CR,
CR, LF.


15.



Each product should have a valid
time on the queue to WMSCR.
This time is presently MIS
products (3 hours),

CWA products
(2 hours), and UA and UUA
products (1 hour). If connectivity
is lost for over one hour, products
with an invalid date/time should be
purged off the WMSCR queue and
not sent. Sending in of products
with an invalid date/time will
cause the W
MSCR edit queue to
fill with messages that need to be
discarded.


16.



Verify the report(s) received do
not exceed any established size
restrictions.


17.


NASAO USERS ONLY

Verify the MD5 Hash value is
appended to the end of the file and
is the correct value.


18.


NASAO USERS DCS
CERTIFICATION ONLY

Verify the raw data file has been
placed in the correct ingest
directory and the MD5 has
contains the correct value for the
data contained in the file.



WMSCR RFS


Page
37

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc


7.1.3

FTP User Download Data.


This test case will verify that FTP u
sers can retrieve data files from the WMSCR ftp server.


Step #

Action:

Result:

Pass/Fail:


1.


Establish the connection between
the WMSCR FTP server and the
client


The FTP client will establish a
socekt connection to the WMSCR
FTP server and perform the lo
gon
sequence as defined in the FTP
RFCs.


The WMSCR FTP server shows a
status of “Connected” for the FTP
c汩e湴⁵湤敲⁴敳琮
=
=



The FTP client should retrieve
data files from WMSCR data
directories as needed.

The FTP client should verify
successful complet
ion of the file
transfer(s).


3.


The FTP client should gracefully
terminate the FTP session.

The FTP client should perform
FTP session termination as defined
in the FTP RFCs.


The the WMSCR FTP server
shows a status of “Disconnected”
景f⁴桥⁆呐⁣汩e湴⁵湤
e爠re獴
=
=
=

WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
38

of
41






7.1.4

Error Conditions and FTP Server Switchover


This test case will verify processing of some common error conditions and verify the FTP user
can connect to the alternate FTP server in the event of a WMSCR FTP server failure..



Step #

Action:

Res
ult:

Pass/Fail:


7.


Establish the connection between
the primary WMSCR FTP server
and the client.


The FTP client will establish a
socekt connection to the WMSCR
FTP server and perform the logon
sequence as defined in the FTP
RFCs.


The WMSCR FTP server sho
ws a
status of “Connected” for the FTP
c汩e湴⁵湤敲⁴敳琮
=
=



From the WMSCR FTP Server,
disable FTP connections for the
FTP client under test.


The FTP client will establish a
socket connection to the alternate
WMSCR FTP server and perform
the logon seque
nce as defined in
the FTP RFCs.


The alternate WMSCR FTP server
shows a status of “Connected” for
瑨攠t呐⁣汩e湴⁵湤敲⁴e獴s
=
=



From the alternate WMSCR FTP
Server, disable FTP connections
for the FTP client under test.


The FTP client will establish a
so
cekt connection to the primary
WMSCR FTP server and perform
the logon sequence as defined in
the FTP RFCs.


The WMSCR FTP primary server
shows a status of “Connected” for
瑨攠t呐⁣汩e湴⁵湤敲⁴e獴s
=
=
=
WMSCR RFS


Page
39

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc


7.1.5

FTP Additional Tests


This section is for any additi
onal tests deemed necessary by either WMSCR personnel or the
FTP user system..


Step #

Action:

Result:

Pass/Fail:


10.





11.





12.





13.





14.





15.







WMSCR RFS

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc

Page
40

of
41






7.2

FTP Test Report

WMSCR FTP RFS Test Report

Subscriber System: _____________________

Date: __________________
____

WMSCR Test Engineer(s): ______________________ Phone:_________________


_______________________ __________________

Subscriber Test Engineer(s): ____________________ Phone: _____________
____


_______________________ __________________


Test Case

Pass/Fail

Notes

7.1.1 FTP Session Establishment.



7.1.2 FTP User Upload Data



7.1.3 FTP User Download Data



7.1.4 Error Conditions
and FTP
Server Switchover



7.1.5 Additional Tests




Additional Information:


Reccommendation:




Final Disposition:




__________________________________ ________________________

WMSCR Test Engineer

Date

WMSCR RFS


Page
41

of
41

I:
\
WMSCR
\
RFS Testing
\
WMSC RFS_Template.doc


8.0

WMSCR DATABASE CHANGE REQUEST

(
to be filled out by WMSCR test engineer and submitted to WMSCR Database team
)

Circuit/Partition:



Date of Request:



Organization/Facility Name:



Desired Change Date:



Initiator’s Name
:



Date Coordinated For Change:

Telephone Number:



Change Number:



DESCRIPTION OF CHANGES:



INI FILE CHANGES

(From 4.2 and 5)



Response Configuration

(attach table from section 5.5)


Input WMO

(attache table from section 5)

Message Distrib
ution


=
fde湴nfy⁗䵏⁨Ma摥牳映f汬⁷=a瑨t爠灲潤畣瑳⁴漠扥⁤楳=物扵瑥搠
by⁗䵓Co⁳y獴敭
a瑴ac栠獨he瑳⁡猠tece獳aryF
=
=
=
FTP Directory






POC Data (WINTOOL)


No changes may be implemented without prior approval by AJW
-
176


APPROVED BY: __________
___________________________________




SLC

801
-
320
-
2093 (Fax)


ATL

770
-
210
-
7203 (Fax)


FAATC
-
609
-
485
-
6783 (Fax)