wmo document templatemeetings.wmo.int/cbs-16/spanish/1. versiones para... · web viewthe report...

Organización Meteorológica MundialCOMISIÓN DE SISTEMAS BÁSICOSDecimosexta reuniónGuangzhou, China, 23 a 29 de noviembre de 2016

CBS-16/Doc. 3.5Presentado por:

Secretario General20.X.2016

VERSIÓN 1

PUNTO 3 DEL ORDEN DEL DÍA: DECISIONES RELACIONADAS CON EL REGLAMENTO TÉCNICO, LAS GUÍAS CORRESPONDIENTES Y LOS TEXTOS DE ORIENTACIÓN

PUNTO 3.5: RECOMENDACIONES RELATIVAS AL MANUAL DEL SISTEMA MUNDIAL DE TELECOMUNICACIÓN

RESUMEN

DECISIONES/MEDIDAS QUE SE SOLICITAN:

a) aprobar el proyecto de Decisión 3.5/1 — Enmiendas a la Guía sobre la ejecución del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial;

b) aprobar el proyecto de Recomendación 3.5/1 — Enmiendas al Manual del Sistema Mundial de Telecomunicación (OMM-N°386) y a sus adjuntos.

CONTENIDO DEL DOCUMENTO:

El índice está disponible únicamente en forma electrónica, como "Mapa del documento"*.

* En PC, en Ms Word 2010, ir a “Vista” y seleccionar la casilla “Panel de navegación” en la sección “Mostrar”. En Ms Word 2007 o 2003, ir a “Vista” > “Mapa del documento”. En Mac, ir a “Vista” > “Panel de navegación”, seleccionar “Mapa del documento” en el menú desplegable de la izquierda.

CBS-16/Doc. 3.5, VERSIÓN 1, p. 2

PROYECTO DE DECISIÓN

Proyecto de Decisión 3.5/1 (CSB-16)

ENMIENDAS A LA GUÍA SOBRE LA EJECUCIÓN DEL CONTROL INTEGRADO DEL FUNCIONAMIENTO DE LA VIGILANCIA METEOROLÓGICA MUNDIAL

LA COMISIÓN DE SISTEMAS BÁSICOS,

Teniendo en cuenta que el adjunto I-5 del Manual del Sistema Mundial de Telecomunicación (OMM-Nº 386), en el que se definen los procedimientos de control cuantitativo de la Vigilancia Meteorológica Mundial, cuenta con el apoyo de la Guía sobre la ejecución del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial,

Teniendo en cuenta además:

1) la Resolución 26 (Cg-17), en la que se introducen los identificadores de estación del WIGOS,

2) las recomendaciones del Grupo de coordinación intercomisiones sobre el Sistema mundial de sistemas de observación de la OMM, según las cuales las estaciones sinópticas de las redes de observación básicas regionales deberán informar cada hora,

3) los formularios enumerados en la Guía sobre la ejecución del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial para la recopilación de estadísticas que no contienen los identificadores de estación del WIGOS,

Considerando que el Sistema de control de calidad de datos del WIGOS recogerá datos estadísticos sobre la disponibilidad de las observaciones para los sistemas de predicción numérica del tiempo y otras aplicaciones,

Decide:

1) que es necesario mantener el funcionamiento paralelo del control cuantitativo de la Vigilancia Meteorológica Mundial y del Sistema de control de calidad de datos del WIGOS durante un período determinado para evaluar la evolución de la disponibilidad de los informes procedentes del Sistema Mundial de Observación;

2) que se mantenga operativo el control integrado del funcionamiento de la Vigilancia Meteorológica Mundial, que recopila datos estadísticas cuatro veces al año;

3) que se actualice la Guía sobre la ejecución del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial, como se muestra en el anexo a la presente Decisión, con el fin de registrar las estadísticas relativas a las observaciones procedentes de estaciones que no disponen de identificadores de cinco caracteres;

4) que todos los centros que participan en el control integrado del funcionamiento de la Vigilancia Meteorológica Mundial faciliten información sobre los informes sinópticos de superficie transmitidos a las 00 UTC, 06 UTC, 12 UTC y 18 UTC, y sobre los informes de observación en altitud transmitidos a las 00Z y las 12 UTC;

5) que los centros que participan en el control integrado del funcionamiento de la Vigilancia Meteorológica Mundial, y estén en condiciones de hacerlo, faciliten información sobre los informes sinópticos de superficie transmitidos cada hora y sobre los informes de observación en altitud sea cual sea la hora de información;


Insta:

1) a todos los Miembros que operan centros regionales de telecomunicaciones a contribuir cada año a la recopilación de estadísticas del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial correspondiente al período del 1 al 15 de octubre,

2) a todos los Miembros que operan centros regionales de telecomunicaciones que forman parte de la Red Principal de Telecomunicaciones a contribuir cada año a la recopilación de estadísticas del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial correspondiente a los períodos del 1 al 15 de enero, del 1 al 15 de abril, del 1 al 15 de julio y del 1 al 15 de octubre;

Pide al Secretario General que actualice el texto de la Guía sobre la ejecución del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial, que realice los ajustes editoriales necesarios y que publique la versión enmendada de la Guía.

______________

Anexo: 1 (disponible en inglés solamente)

World Meteorological OrganizationOrganisation météorologique mondiale

Temps ● Cl ima t ● Eau Weath e r ● Cl imat e ● Water


Annex to draft Decision 3.5/1 (CBS-16)

TEXT OF THE GUIDE ON THE IMPLEMENTATION OF THE INTEGRATED WWW MONITORING (ENGLISH ONLY)

GUIDE ON THE IMPLEMENTATION OF THE INTEGRATED WWW MONITORING

Contents

1. Main features of the IWM .........................................................................5

2. Changes in the procedures of the monitoring exercises ...........................5

3. Transition from AGM to the IWM ...............................................................6

4. Plans for the implementation of the IWM .................................................6

Annex: Procedures for the preparation and exchange of the IWM quarterly summary reports ......................................................................................9

1. Introduction..............................................................................................9

2. Format of directories and sub-directories .................................................9

3. File names ..............................................................................................10

4. Format of presentation ...........................................................................11

5. NMC Quarterly Monitoring ......................................................................11

6. RTH quarterly monitoring .......................................................................13

7. RTH/MTN quarterly monitoring ...............................................................15

8. Questionnaire on the implementation of the monitoring procedures .....16


1. Main features of the IWM

The Integrated WWW Monitoring leads to the integration of the Annual Global Monitoring (AGM) and the Special MTN Monitoring (SMM) into one monitoring scheme. The main features of the IWM are as follows:

1.1 As for the Annual Global Monitoring (AGM), the centres should at least monitor the part of the global data set for which they are responsible to collect and forward on the GTS: National Meteorological Centres (NMCs) should at least monitor data from their own

territory; Regional Telecommunication Hubs (RTHs) should at least monitor data from their

associated NMCs, and possibly from their own Region; World Meteorological Centres (WMCs) and RTHs located on the Main

Telecommunication Network (MTN) should monitor the complete global data set.

1.2 As for the AGM, the The monitored data set should include the observations from the stations included from the Regional Basic Synoptic Networks (RBSNs) for the main synoptic hours (00, 06, 12 and 18 UTC) and from the stations included in the Regional Basic Climatological Networks (RBCNs). ; observations from stations in the RBON (Regional Basic Observing Networks) will be monitored when they are defined . The types of data to be monitored are further detailed in Table A of the Annex.

1.3 The monitored data set should include the data represented in Traditional Alphanumeric Codes (TAC) and in Table-Driven Code Forms (BUFR, CREX).

1.4 The monitoring periods are: 1-15 January, April, July and October.

1.5 The flow of the monitoring reports is as follows (see Figure 2 ): NMCs prepare quarterly summary reports and send them to their associated RTHs; RTHs compile the summary reports received from the NMCs in their zones of

responsibility together with their own monitoring summaries and send their quarterly RTH summary reports to the associated RTH on the MTN and the WMO Secretariat;

RTHs on the MTN participating in the Special MTN Monitoring (SMM) continue sending their raw data to the Secretariat and the other RTHs on the MTN send quarterly RTH/MTN summary reports to the Secretariat

The monitoring reports should be exchanged preferably before the end of the month of monitoring, and not later than the 15th of the following month.

1.6 The analysis of the monitoring reports is expected to be prepared by the RTHs at the Regional level and by the Secretariat at the global level.

2. Changes in the procedures of the monitoring exercises

2.1 There are no changes in the implementation of the SMM. It is expected that the SMM will continue being extended in order to monitor the data exchanged in table-driven code forms.

2.2 The NMCs prepare NMC quarterly summary reports instead of annual AGM reports. The information contained in the AGM reports for the 15 days monitoring period can be used to prepare these new reports. The NMCs send their quarterly summary reports to the associated RTHs, and not to the WMO Secretariat.

2.3 The RTHS receive the monitoring reports from their associated NMC, compile them into quarterly RTH summary reports, and send them to the associated RTH on the MTN and the WMO Secretariat, instead of sending annual AGM reports.


2.4 The RTHs on the MTN, that do not participate in the Special MTN Monitoring (SMM), send quarterly RTH/MTN summary reports to the Secretariat instead of sending the AGM reports.

2.5 The flow of the monitoring reports before and after the implementation of the IWM are shown in Figures 1 and 2 respectively.

3. Transition from AGM to the IWM

3.1 The AGM reports are replaced by the NMC quarterly summary reports, the quarterly RTH summary reports and the quarterly RTH/MTN reports. The information contained in the AGM reports for the 15 days monitoring period can be used to prepare these new reports. The RTHs can therefore prepare the RTH summary reports from the AGM reports or the NMC quarterly summary reports, and each associated NMC can define with its associated RTH a plan for moving from the transmission to the RTH of the AGM reports to the transmission of the NMC summary reports. This facilitates the phased integration of the AGM into the IWM through a step by step approach at the level of each NMC.

3.2 Once an NMC and its associated RTH prepare the NMC and the RTH quarterly summary reports covering the territory of the NMC for a set of data and that the RTH sends the relevant quarterly summary report to the Secretariat, the NMC and its associated RTH can stop sending the AGM reports covering the territory of the NMC to the Secretariat for that set of data.

3.3 Once an RTH on the MTN sends its RTH/MTN quarterly summary report covering the global data set to the Secretariat for a set of data, the RTH can stop sending its AGM reports to the Secretariat for that set off data.

3.4 The use of a monitoring application on a PC facilitates the implementation of the IWM at the NMCs, RTHs and RTHS on the MTN. Germany has offered the METDATA Monitoring software for use, free of charge, to WMO and all its Members; the software can be used on a PC to implement the AGM and the IWM.

4. Plans for the implementation of the IWM

4.1 Preparation and exchange of NMC and RTH quarterly summary reports

Each RTH on the MTN should coordinate the development of a plan for the preparation and the exchange of NMC and RTH quarterly summary reports issued from its zone of responsibility:

The RTH informs its associated NMCs and the WMO Secretariat of its plan for the preparation of its RTH quarterly summary reports for each type of data defined by the abbreviated headings of the bulletins containing the data (see Table A of the Annex).

The associated NMCs inform the RTH and the WMO Secretariat of their plan for the preparation of their NMC quarterly summary reports for each type of data defined by the abbreviated headings of the bulletins containing the data (see Table A of the Annex).

The RTH maintains a table of the planned and effective dates of the implementation of the NMC and RTH quarterly summary reports for each type of data, and posts the updated table on the WMO FTP server (subdirectory …/GTS_monitoring/IWM/RTH_plans/…).

4.2 Preparation and exchange of RTH/MTN quarterly summary reports

Each RTH on the MTN should develop a plan for the preparation and the exchange of its RTH/MTN quarterly summary reports for each type of data and and posts the updated


table on the WMO FTP server (subdirectory …/GTS_monitoring/IWM/RTH_plans/…).

Figure 1 – Flow of monitoring reports before implementation of the IWM

Brack


Annex: Procedures for the preparation and exchange of the IWM quarterly summary reports

1. Introduction

If a monitoring centre experiences difficulties in introducing the format or part of it, this centre is invited to clearly indicate the part of the format, that it could not use, in the field "remarks" of the questionnaire on the implementation of monitoring procedures (see hereunder paragraph 7).

2. Format of directories and sub-directories

CCCC.YYM|| DMsdsdsMedede.TTT

(a) CCCC.YYM directory name and extension.

CCCC = Location Indicator of the monitoring centre (e.g. EGRR = RTH Exeter ,

YY = Starting year of the monitoring (e.g. 07 = 2007),

M = Starting month of the monitoring (1 = January, .., 9 = September, A = October, B = November and C = December).

(b) DMsdsdsMedede.TTT subdirectory name and extension.

D = Type of monitoring (G = global, R = regional, N = national, S = special, B = bilateral etc.);

Ms = Starting month of monitoring (1 = January, …, 9 = September, A = October, B = November and C = December).

dsds = Starting date of monitoring (the date of the month/ Ms);

Me = Ending month of monitoring (1 = January, …, 9 = September, A = October, B = November and C = December).

dede = Ending date of monitoring (the date of the month/ Me);

TTT = Type of files in this subdirectory: DBF for dBase, ASC for ASCII.

Example: EGRR.07A (monitoring carried out by RTH Exeter in October 2007)|| GA01A15.TXT - Type of monitoring: global

- Period: from 1 to 15 October- Type of files under this subdirectory: TXT


3. File names

The file names should be: WYYYY MMdsds dedeCCCCDDP.TTT, with

W Type of quarterly summary report (N for NMC summary report, R for RTH summary report, G for RTH/MTN summary report)

YYYY Starting year of the monitoring (e.g. 2007)MM Ending month of monitoring (01 for January, …, 12 for December)dsds Starting day of monitoringdede Ending day of monitoringCCCC Location indicator (CCCC) of the monitoring centre.DDP See Table ATTT Type of files, e.g. ASC or TXT for ASCII, DBF for dBase

Table A - DDP

Type of data DDValue of P according to the form of representation of the monitored dataP = A for Traditional

Alphanumerical Codes (TAC)

P = B for BUFR

P = C for CREX

TAC T1 T2* T1 T2 A1* T1 T2 A1*Surface observations from fixedstations

SY SYNOP SM, SI,SN

ISM, ISI,ISN

KSM, KSI,KSN

Radiosonde observations from fixed stations

TT TEMP US IUK, IUS KUK, KUS

Radiowind observations from fixed stations

PP PILOT UP IUJ, IUW KUJ, KUW

Climatic observations from fixed surface stations

CL CLIMAT CS ISC KSC

Surface observations from marine stations

SH SHIP SM, SI ISS KSS

Radiosonde observations from marine stations

TS TEMP SHIP

US IUK, IUS KUK, KUS

Radiowind observations from marine stations

PS PILOT SHIP

UP IUJ, IUW KUJ, KUW

Buoy observations BU BUOY SS IOB KOBSea surface and below soundings

BT BATHY/TE SAC/TRA CKOB

SO IOP, IOR, IOS

KOP, KOR, KOS

Aircraft reports AI AIREP UAAM AMDAR UDBA IUA, IUO KUA, KUO

Observations from wind profilers BP IUP KUP* The columns T1 T2 or T1 T2 A1 of this Table contains the first letters of the abbreviated headings of the bulletins containing the data set to be monitored

Example: N2007100115KWBCSYA.ASC (SYNOP monitored by WMC/RTH Washington from 1 to 15 October 2007, type ASCII).

CBS-16/Doc.3.5, VERSIÓN 1, p. 10

4. Format of presentation

Each report shall consist of a number of data lines organised organized into files defined by data type and formatted as given below. All fields would be surrounded by double-quotation marks (") and separated by commas.

5. NMC Quarterly Monitoring

5.1 Format for DD = SY (e.g. TAC SYNOP reports)

Field Width Description1 3 Value of DDP (See Table A) (e.g. SYA)2 4 International location indicator of the monitoring centre3 5 WMO station index number4 2 Synoptic hour of observation (i.e. 00, 01, etc.)5 2 Number of reports available within 1 hour after the hour of observation6 2 Total number of reports available after 1 hour after the hour of observation7 30 WIGOS station identifier

Example: contents of file "N2007100115EBBRSYA.TXT" (October 2007- SYNOP for EBBR) "SYA","EBBR","06400","00","12","15","0-20000-0-06400""SYA","EBBR","06400","12","15","15","0-20000-0-06400""SYA","EBBR","06401","00","14","15","0-20000-0-06400""SYA","EBBR","06401","06","12","15","0-20000-0-06401""SYA","EBBR","06401","12","15","15","0-20000-0-06401""SYA","EBBR","06401","18","10","13","0-20000-0-06401"

5.2 Format for DD = TT or PP (e.g. radiosonde observations in BUFR)

Field Width Description1 3 Value of DDP (See Table A) (e.g. TTB)2 4 International location indicator of the monitoring centre3 5 WMO station index number4 2 Synoptic hour of observation (i.e. 00, 06, 12 or 18 UTC)5 2 Number of reports available within 2 hours after the hour of observation6 2 Total number of reports available after 2 hours after the hour of

observation7 30 WIGOS station identifier

Example: contents of file "N2007100115EBBRTTB.TXT" (October 2007 – radiosonde observations in BUFR for EBBR)"TTB","EBBR","06400","00","15","15","0-20000-0-06400""TTB","EBBR","06400","12","15","15","0-20000-0-06400""TTB","EBBR","06401","00","14","15","0-20000-0-06400 " "TTB","EBBR","06401","06","15","15","0-20000-0-06401""TTB","EBBR","06401","12","15","15","0-20000-0-06401""TTB","EBBR","06401","18","14","14","0-20000-0-06401"

5.3 Format for DD = CL (e.g. TAC CLIMAT reports)


Field Width Description1 3 Value of DDP (See Table A) (e.g. CLA)2 4 International location indicator of the monitoring centre3 5 WMO station index number4 1 =1 if the report of the previous month is available, =0 otherwise5 30 WIGOS station identifier

Example: contents of file "N2007100115EBBRCLA.TXT" (October 2007 – September CLIMAT reports for EBBR)"CLA","EBBR","06400","1","0-20000-0-06400""CLA","EBBR","06401","1","0-20000-0-06401"

5.4 Format for DD = SH, TS or PS (e.g. TAC TEMP SHIP reports)

Field Width Description1 3 Value of DDP (See Table A) (e.g.TSA)2 4 International location indicator of the monitoring centre3 11 Abbreviated heading TTAAii CCCC of the bulletin4 2 Synoptic hour of observation (i.e. 00, 01, etc.)5 5 Number of available bulletins6 7 Number of available reports

Example: contents of file "N2007100115LEMMTSA.TXT" (October 2007 – TEMP SHIP reports for LEMM)"TSA","LEMM","USVA01 LEMM","00","22","134""TSA","LEMM","USVA01 LEMM","06","24","163""TSA","LEMM","USVA01 LEMM","12","25","115""TSA","LEMM","USVA01 LEMM","18","88","211""TSA","LEMM","USVA13 LEMM","00","33","135""TSA","LEMM","USVA13 LEMM","06","45","173""TSA","LEMM","USVA13 LEMM","12","34","414""TSA","LEMM","USVA13 LEMM","18","10","192"

5.5 Format for DD = BU, BT, AI, AM, BA or BP (e.g. TAC BATHY/TESAC/TRACKOB reports)

Monitoring reports should list the number of bulletins and reports compiled from 2100 to 0259 UTC, 0300 to 0859 UTC, 0900 to 1459 UTC and 1500 to 2059 UTC with one data line per time period. Each data line will contain the ending time of the compiled period rounded up to the nearest hour. For example, data compiled from 2100 to 0259 would be indicated as hour 03.

Field Width Description1 3 Value of DDP (See Table A) (e.g.BTA)2 4 International location indicator of the monitoring centre3 11 Abbreviated heading TTAAii CCCC of the bulletin4 2 Ending time of the compiled period rounded up to the nearest hour5 5 Number of available bulletins6 7 Number of available reports

Example: contents of file "N2007100115LFPWBTA.TXT" (October 2007 – BATHY/TESAC/TRACKOB reports for LFPW)"BTA","LFPW","SSVX01 LFPW","03","24","163""BTA","LFPW","SSVX01 LFPW","09","25","115"


"BTA","LFPW","SSVX01 LFPW","15","88","211""BTA","LFPW","SSVX01 LFPW","21","22","134""BTA","LFPW","SSVX13 LFPW","03","45","173""BTA","LFPW","SSVX13 LFPW","09","34","414""BTA","LFPW","SSVX13 LFPW","15","10","192""BTA","LFPW","SSVX13 LFPW","21","33","135"

6. RTH quarterly monitoring

Four times per year every RTH, including RTHs on the MTN, should provide monitoring reports on the availability of observations within its area of responsibility. The reports should list the number of observations reported as available by the associated NMCs in their quarterly reports compared with the number of observations received at the RTH during the monitoring period. The reports should be sent to the Secretariat and to the RTH’s associated RTH on the MTN as quickly as possible, preferably within 10 days.

6.1 Format for DD = SY (e.g. TAC SYNOP reports)

Field Width Description1 3 Value of DDP (See Table A) (e.g. SYA)2 4 International location indicator of the NMC3 4 International location indicator of the RTH4 5 WMO station index number5 2 Synoptic hour of observation (i.e. 00, 01, etc.)6 2 Number of reports available at the NMC within 1 hour after the hour of

observation7 2 Total number of reports available at the NMC after 1 hour after the hour of

observation8 2 Number of reports available at the RTH within 1 hour after the hour of

observation9 2 Total number of reports available at the RTH after 1 hour after the hour of

observation10 30 WIGOS station identifier

Example: contents of file "R2007100115LEMMLFPWSYA.TXT" "SYA","LEMM","LFPW","08001","00","12","15","12","15","0-20000-0-08001""SYA","LEMM","LFPW","08001","06","15","15","15","15","0-20000-0-08001""SYA","LEMM","LFPW","08001","12","14","15","14","15","0-20000-0-08001""SYA","LEMM","LFPW","08001","18","8","14","8","13","0-20000-0-08001"

6.2 Format for DD = TT or PP (e.g. radiosonde observations in BUFR)

Field Width Description1 3 Value of DDP (See Table A) (e.g. TTB)2 4 International location indicator of the NMC3 4 International location indicator of the RTH4 5 WMO station index number5 2 Synoptic hour of observation (i.e. 00, 06, 12 or 18 UTC)6 2 Number of reports available within 2 hours after the hour of observation7 2 Number of reports available at the NMC within 2 hours after the hour of

observation


8 2 Total number of reports available at the NMC after 2 hours after the hour of observation

9 2 Number of reports available at the RTH within 2 hours after the hour of observation

10 30 WIGOS station identifier

Example: contents of file "R2007100115LEMMLFPWTTB.TXT" "TTB","LEMM","LFPW","08001","00","15","15","15","15","0-20000-0-08001""TTB","LEMM","LFPW","08001","12","15","15","15","15","0-20000-0-08001""TTB","LEMM","LFPW","08023","00","14","15","14","15","0-20000-0-08023""TTB","LEMM","LFPW","08023","12","12","15","12","15","0-20000-0-08023"

6.3 Format for DD=CL (e.g. TAC CLIMAT reports)

Field Width Description1 3 Value of DDP (See Table A) (e.g. CLA)2 4 International location indicator of the NMC3 4 International location indicator of the RTH4 5 WMO station index number5 1 =1 if the report of the previous month is available at the NMC, =0

otherwise6 1 =1 if the report of the previous month is available at the RTH, =0

otherwise7 30 WIGOS station identifier

Example: contents of file " R2007100115LPMGLFPWCLA.TXT"

"CLA","LPMG","LFPW","08501","1","1","0-20000-0-08501""CLA","LPMG","LFPW","08506","1","1","0-20000-0-08506""CLA","LPMG","LFPW","08509","1","1","0-20000-0-08509"

6.4 Format for DD = SH, TS or PS (e.g. TAC TEMP SHIP reports)

Field Width Description1 3 Value of DDP (See Table A) (e.g.TSA)2 4 International location indicator of the NMC3 4 International location indicator of the RTH4 11 Abbreviated heading TTAAii CCCC of the bulletin5 2 Synoptic hour of observation (i.e. 00, 01, etc.)6 5 Number of bulletins available at the NMC7 7 Number of reports available at the NMC8 5 Number of bulletins available at the RTH9 7 Number of reports available at the RTH

Example contents of file "R2007100115LPMGLFPWTSA.TXT" "TSA","LPMG","LFPW","SMVX01 LPMG","00","24","163","24","163""TSA","LPMG","LFPW",SMVX01 LPMG","00","24","163","24","163"


6.5 Format for DD = BU, BT, AI, AM or BA or BP (e.g. AIREP reports)Monitoring reports should list the number of bulletins and reports compiled from 2100 to 0259 UTC, 0300 to 0859 UTC, 0900 to 1459 UTC and 1500 to 2059 UTC with one data line per time period. Each data line will contain the ending time of the compiled period rounded up to the nearest hour. For example, data compiled from 2100 to 0259 would be indicated as hour 03.

Field Width Description1 3 Value of DDP (See Table A) (e.g.AIA)2 4 International location indicator of the NMC3 4 International location indicator of the RTH4 11 Abbreviated heading TTAAii CCCC of the bulletin5 2 Ending time of the compiled period rounded up to the nearest hour6 5 Number of bulletins available at the NMC7 7 Number of reports available at the NMC8 5 Number of bulletins available at the RTH9 7 Number of reports available at the RTH

Example: contents of file "R 2003100115LPMGLFPWAIA.TXT" "AIA","LPMG","LFPW","UAEW01 LPMG","03","24","163","24","163""AIA","LPMG","LFPW","UAEW01 LPMG","09","21","152","21","152""AIA","LPMG","LFPW","UAEW01 LPMG","15","19","143","19","143""AIA","LPMG","LFPW","UAEW01 LPMG","21","20","149","20","149"

7. RTH/MTN quarterly monitoring

In addition to the RTH quarterly monitoring reports produced by every RTH, it is recommended that RTHs on the MTN that do not participate in the SMM also produce a report on all of the data received at their centre and pass these reports to the WMO Secretariat for comparison with other MTN centres. The report should monitor all data of all of the types listed in Table A, that are received at the RTH. The formats and file names of the reports should conform to those defined for the NMC quarterly reports; the first letter of the file names should be "G".


8. Questionnaire on the implementation of the monitoring procedures

As for the AGM, the centres are invited to provide information on the implementation of the monitoring procedures in a file named CCCCQUZ.TXT with the following structure:

Field Width Description1 4 Location indicator (CCCC) of the monitoring centre2 1 = 1 if the monitoring is automated, = 0 otherwise3 1 = 1 if the counting of bulletins and reports is performed before quality control, = 0

otherwise4 1 = 1 if the bulletins and reports are counted only if received or transmitted on the

GTS channels, = 0 otherwise5 1 = 1 if the duplicated bulletins are disregarded, = 0 otherwise6 1 = 1 if the bulletins including only NIL reports are counted, = 0 otherwise7 1 = 1 it the bulletins including the indicator COR or CCx are counted in addition to

bulletins to be corrected, =0 otherwise8 1 = 1 if the duplicated reports from fixed stations included in bulletins having the

same abbreviated heading are disregarded, = 0 otherwise9 1 = 1 if the duplicated reports from fixed stations included in bulletins having different

abbreviated headings are disregarded, = 0 otherwise10 1 = 1 if NIL reports are disregarded, = 0 otherwise11 1 = 1 if reports from fixed stations included in bulletins with the indicator COR or CCx

are disregarded to avoid double counting of these reports, = 0 otherwise12 1 = 1 if all AIREP/AMDAR reports made at different positions during the flight are

counted as different reports, = 0 otherwise13 1 = 1 if the monitoring implemented by using the METDATA monitoring software

provided by Germany, = 0 otherwise1450 Remarks.

______________


PROYECTO DE RECOMENDACIÓN

Proyecto de Recomendación 3.5/1 (CBS-16)

ENMIENDAS AL MANUAL DEL SISTEMA MUNDIAL DE TELECOMUNICACIÓN(OMM-N° 386) Y A SUS ADJUNTOS

LA COMISIÓN DE SISTEMAS BÁSICOS,

Teniendo en cuenta:

1) el adjunto I-5 del Manual del Sistema Mundial de Telecomunicación (OMM-N° 386), volumen I, en el que se definen los procedimientos de control cuantitativo de la Vigilancia Meteorológica Mundial,

2) la necesidad de actualizar el Manual del Sistema Mundial de Telecomunicación para definir las áreas de responsabilidad y el encaminamiento preferido de los centros regionales de telecomunicaciones con arreglo a lo dispuesto en la Resolución 32 (Cg-17) tras la suspensión del volumen II del Manual del Sistema Mundial de Telecomunicación (OMM-N° 386),

3) el adjunto II-15 del Manual del Sistema Mundial de Telecomunicación, en el que se definen las prácticas y los procedimientos recomendados para la instalación, utilización y aplicación en el Sistema Mundial de Telecomunicación del Protocolo de control de transmisión/protocolo Internet (TCP/IP)

4) la Guide to Information Technology Security (Guía sobre la seguridad de la tecnología de la información) (WMO-Nº 1115),

5) la Guide to Virtual Private Networks (VPN) via the internet between GTS centres (Guía sobre redes privadas virtuales por Internet entre centros del Sistema Mundial de Telecomunicación) (WMO-Nº 1116),

Teniendo en cuenta además:

1) la importancia de mantener la vigencia de las directrices operativas para garantizar el funcionamiento eficaz y seguro del SMT,

2) la utilización del “procedimiento acelerado” para introducir designadores de datos en el adjunto I-5 del Manual del Sistema Mundial de Telecomunicación en apoyo de la aviación civil internacional,

Recomienda al Consejo Ejecutivo que enmiende el Manual del Sistema Mundial de Telecomunicación y sus adjuntos, según se define en los anexos a la presente recomendación:

1) enmiendas al adjunto II-5 del Manual del Sistema Mundial de Telecomunicación, según se define en el anexo 1 a la presente recomendación;

2) enmiendas a la parte 1 y a los adjuntos I-2 y I-3 del Manual del Sistema Mundial de Telecomunicación, según se define en el anexo 2 a la presente recomendación;

3) enmiendas al adjunto II-15 del Manual del Sistema Mundial de Telecomunicación, según se define en el anexo 3 a la presente recomendación;

4) enmiendas a la Guide to Information Technology Security (Guía sobre la seguridad de la tecnología de la información) (WMO-Nº 1115), conforme a lo dispuesto en el anexo 4 a la presente recomendación;


5) enmiendas a la Guide to Virtual Private Networks (VPN) via the internet between GTS centres (Guía sobre redes privadas virtuales por Internet entre centros del Sistema Mundial de Telecomunicación) (WMO-Nº 1116), con arreglo al anexo 5 de la presente recomendación.

__________Anexos: 5


Anexo 1 al proyecto de Recomendación 3.5/1 (CBS-16)

ENMIENDAS AL ADJUNTO I-5 DEL MANUAL DEL SISTEMA MUNDIAL DE TELECOMUNICACIÓN (OMM-N° 386)

1 En la sección 4 del adjunto I-5 (Prioridades)

Añadir una nota después de la lista de los tipos de información que figura en el párrafo 4.1:

Nota: Las referencias a los tipos de informe incluyen la información en cualquiera que sea la clave de la Vigilancia Meteorológica Mundial en que esté representada.

Enmendar el párrafo 4.2 de la siguiente manera:

4.2 El control de los datos de los satélites constituye un caso especial. Existen solamente unos cuantos operadores y sus normas para el control, incluido el control de la calidad de los datos procedentes de satélites, son ya altas. El control de los boletines de datos de los satélites y de los boletines cifrados en la clave GRID GRIB constituirá un caso especial durante algún tiempo según indique la Secretaría de la OMM.

2 En la sección 5 del adjunto I-5 (Responsabilidades)


5.5 A fin de poder evaluar periódicamente la eficacia del funcionamiento de la VMM, el control coordinado a nivel internacional en tiempo no real deberá efectuarse periódicamente sobre la totalidad de los datos mundiales de observación, una vez cuatro veces al año en el mes los meses de octubre, enero, abril y julio, con la participación de un número limitado de centros principales de la VMM. Durante otros períodos, deberán controlarse sectores de problemas específicos, ya sea con respecto a alguna información solamente o para determinadas partes del mundo. El Secretario General organizará, en consulta con los centros correspondientes, los detalles de los ejercicios especiales de control y los períodos durante los cuales deben llevarse a cabo, y dará los oportunos avisos con mucha antelación.

3 En la sección 6 del adjunto I-5 (Procedimientos)


6.1 Por lo que respecta al control en tiempo real, cada centro elaborará los procedimientos detallados que se necesitan a estos efectos. Estos procedimientos variarán de un centro a otro, pero deben concebirse de tal modo que faciliten el control en tiempo real de la recepción de los boletines y observaciones, según proceda. En los centros totalmente automatizados, estos procedimientos podrán abarcar la utilización de registros de sistemas de telecomunicación, equipos de presentación visual, programas especiales de computadoras para telecomunicaciones y procesamiento de datos, y así sucesivamente. En los centros manuales, podrán confeccionarse listas u hojas de control para los mismos propósitos utilizando marcas, cruces o cifras que indiquen las horas a las que se han recibido determinados boletines y/o informes. Para evitar la utilización excesiva de formularios, quizá convenga colocar hojas de plástico transparentes sobre las hojas de control y hacer los registros utilizando lápices de mina suave. Las cifras pueden suprimirse muy fácilmente cuando ha pasado un período de tiempo conveniente y las hojas preparadas para los controles pueden volver a utilizarse para un período ulterior. En la tabla C se dan nuevas orientaciones sobre el funcionamiento del control en tiempo real, junto con ejemplos del tipo de formularios que podrían confeccionarse.


6.2 Por lo que respecta al control en tiempo no real, cuando la Secretaría solicita la realización de ejercicios especiales, en el momento de presentarse la solicitud se indicará la forma en que han de hacerse las contribuciones. Es importante que, en la medida de lo posible, los centros se ajusten detalladamente a los procedimientos indicados con el fin de que los resultados de los diversos centros sean directamente comparables. Es particularmente importante que así sea cuando se realiza el ejercicio mundial anual de control. En la tabla D figuran los procedimientos, junto con los formularios formatos normalizados que han de utilizarse para dar los resultados.

4 En la tabla C (Directrices para el control en tiempo real) del adjunto I-5

Añadir una nota inmediatamente después del título de la tabla C:

Nota: En esta tabla, las menciones al tipo de informe (como SYNOP) se refieren a la información en cualquiera que sea la clave de la Vigilancia Meteorológica Mundial en que esté representada.

5 En la tabla D del adjunto I-5 (Procedimientos para el control internacionalmente coordinado en tiempo no real)

Enmendar el párrafo (Períodos de control) de la manera siguiente:

El control de datos coordinado internacionalmente para el intercambio mundial se efectuará una vez cuatro veces al año, en octubre, enero, abril y julio, con miras a verificar periódicamente la eficacia de funcionamiento de la VMM. Los centros operados manualmente y los automatizados Se deberán recopilar estadísticas para el período del 1º al 5 de octubre y, los períodos del 1 al 15 de octubre, del 1 al 15 de enero, del 1 al 15 de abril y del 1 al 15 de julio respectivamente. Con el fin de facilitar la comparación de resultados entre los dos tipos de centros, los centros automatizados deberán proporcionar también los resultados correspondientes a ambos períodos, del 1º al 5 de octubre y del 1º al 15 de octubre.

Nota: En lo que respecta a CLIMAT, el período de control debe ampliarse a 15 días, incluso si (para otras observaciones) se hace un retorno para un período de sólo cinco días.

Enmendar el párrafo 2 (Tipos de datos que deberán controlarse) de la siguiente manera:

Deberán controlarse los tipos de datos enumerados en la siguiente tabla:

Tipos de datosEncabezamientos abreviados de boletines T1T2A1A2

Formulario de referencia para presentación de resultado (véase http://wis.wmo.int/iwm)

Informes SYNOPInformes TEMP, Partes A y BInformes PILOT, Partes A y BInformes SHIPInformes TEMP SHIP, Partes A y BInformes PILOT SHIP, Partes A y BInformes BUOYInformes AIREPInformes AMDARInformes BATHY/TESAC/TRACKOBInformes CLIMAT

SMA1A2/ISMA2/ISNA2USA1A2/UKA1A2/IUKA2UPA1A2/UGA1A2/IUJA2SMA1A2/ISSA2USA1A2/UKA1A2/IUKA2UPA1A2/UGA1A2/IUJA2SSA1A2/IOBA2UAA1A2/IUAA2UDA1A2/IUAA2/IUOA2SOA1A2/IOSA2CSA1A2/ISCA2

AB1/B2B1/B2C1/C2D1/D2/D3/D4D5/D6/D7/D8EFGHI1

a) Control de informes SYNOP

Para cada estación controlada identificada por el indicativo de estación del WIGOS y, en su caso, por el número índice de estación (IIiii) de la Vigilancia Meteorológica Mundial, el número de informes SYNOP correspondientes a las horas sinópticas estándar principales (00, 06, 12 y


18 utc), disponibles durante el período de control dentro de una, dos y seis horas, de las correspondientes al boletín estándar, deberá insertarse en las columnas apropiadas del formulario a registrarse en el archivo correspondiente definido en la dirección http://wis.wmo.int/iwm;

b) Control de las Partes A y B de informes TEMP y PILOT (o a 100mb para los informes en claves determinadas por tablas)

Para cada estación controlada identificada por el indicativo de estación del WIGOS y, en su caso, por el número índice de estación (IIiii) de la Vigilancia Meteorológica Mundial, el número de las Partes A y B de informes TEMP y PILOT hechos por seguimiento de un globo libre por medios electrónicos u ópticos a las horas sinópticas fijas principales (0000, 0600, 1200 y 1800 UTC) y disponibles durante el período de control de 2 horas y 12 horas subsiguiente a la hora oficial del boletín deberá insertarse en las columnas correspondientes de los formularios B1 y B2 registrarse en el archivo correspondiente definido en la dirección http://wis.wmo.int/iwm ;

c) Control de informes SHIP

El número de boletines identificados por sus encabezamientos abreviados (T1T2A1A2ii CCCC), entre ellos los informes SHIP, hechos a las horas sinópticas principales (0000, 0600, 1200 y 1800 UTC) y disponibles durante el período de control de 2 horas y 12 horas subsiguiente a la hora oficial del boletín, así como el número de informes incluidos en estos boletines deben insertarse en las columnas correspondientes de los formularios C1 y C2 registrarse en el archivo correspondiente definido en la dirección http://wis.wmo.int/iwm ;

d) Control de las Partes A y B de informes TEMP y PILOT y PILOT SHIP (o a 100mb para los informes en claves determinadas por tablas)

El número de boletines identificados por sus encabezamientos abreviados (T1T2A1A2ii CCCC), entre ellos las Partes A y B de informes TEMP y PILOT, y PILOT SHIP (o a 100mb para los informes en claves determinadas por tablas), hechos a las horas sinópticas principales (0000, 0600, 1200 y 1800 UTC) y disponibles durante el período de control de 12 horas y 24 horas subsiguiente a la hora oficial del boletín, así como el número de informes incluidos en estos boletines deben insertarse en las columnas correspondientes de los formularios D1 a D8 registrarse en el archivo correspondiente definido en la dirección http://wis.wmo.int/iwm ;

e) Control de informes BUOY, AIREP y AMDAR

El número de boletines identificados por sus encabezamientos abreviados (T1T2A1A2ii CCCC) entre ellos los informes BUOY, AIREP y AMDAR, compilados entre 2100 y 0259 UTC, 0300 y 0859 UTC, 0900 y 1459 UTC, y 1500 y 2059 UTC, y disponibles durante el período de control antes de 0500, 1100, 1700 y 2300 UTC respectivamente, así como el número de informes incluidos en estos boletines deberán insertarse en las columnas correspondientes a los formularios E, F y G registrarse en el archivo correspondiente definido en la dirección http://wis.wmo.int/iwm;

f) Control de BATHY/TESAC/TRACKOB

La hora de recepción de los boletines identificados por sus encabezamientos abreviados completos (T1T2A1A2ii CCCC YYGGgg (BBB)) que contienen informes BATHY/TESAC/TRACKOB, así como el número de informes incluidos en estos boletines deberán insertarse en las columnas correspondientes del formulario H registrarse en el archivo correspondiente definido en la dirección http://wis.wmo.int/iwm ;

g) Control de informes CLIMAT

Para cada estación controlada e identificada por el indicativo de estación del WIGOS y, en su caso, por el número de índice de estación (IIiii) de la Vigilancia Meteorológica Mundial, “I” deberá insertarse registrarse“I” en la columna correspondiente del formulario I1 si el informe


CLIMAT de septiembre se recibe entre el 1 y el 5 de octubre o entre el 6 y el 15 de octubre; en los demás casos deberá insertarse “0” en estas columnas en el archivo correspondiente definido en la dirección http://wis.wmo.int/iwm .

Enmendar el párrafo 5 (Aplicación de los procedimientos de control y cuestionarios) de la manera siguiente:

5.1 Los cuestionarios relacionados El cuestionario relacionado con los procedimientos aplicados en los centros, la suspensión de programas de observación en estaciones de observación y la suspensión de la transmisión por circuitos se indican en los formularios J, K y L, respectivamente figura en la sección “Questionnaire on the implementation of the monitoring procedures” (Cuestionario sobre la aplicación de los procedimientos de control) en la dirección http://wis.wmo.int/iwm.

5.2 Los procedimientos de control deben aplicarse en los centros de tal manera que todas las respuestas a los cuestionarios las preguntas incluidas en formulario J el cuestionario sean positivas (respuesta: Sí 1 ). Las preguntas 7, 8 y 10 son aplicables únicamente a los informes SYNOP, TEMP, PILOT y CLIMAT.

Enmendar el párrafo 6.1 (Formularios normalizados para estadísticas) de la manera siguiente:

6.1 Con vista a permitir una fácil comparación de los resultados de un control coordinado internacionalmente, realizado por diferentes centros, deben utilizarse los formularios normalizados adjuntos que se especifican en la dirección http://wis.wmo.int/iwm. Todos los centros que efectúan el control deben indicar claramente el período cubierto. En cada formulario, los centros deben presentar los resultados región por región y para la Antártida, y dar los totales de los números de boletines o informes recibidos dentro del tiempo especificado región por región y para la Antártida

Eliminar el párrafo 6.2 actual y modificar la numeración del párrafo 6.3, que pasará a ser el párrafo 6.2.

Eliminar las tablas que contienen los formularios A a L, ambos incluidos (páginas 37 a 58 de la edición en español).

__________

http://wis.wmo.int/GTS-manual



ENMIENDAS AL MANUAL DEL SISTEMA MUNDIAL DE TELECOMUNICACIÓN (OMM-N° 386)

1. Enmendar el párrafo 1.1 de la sección 1, parte I, de la manera siguiente

1.1 Funciones

Las funciones del Sistema Mundial de Telecomunicación (SMT), como componente fundamental del Sistema de información de la OMM (SIO), consistirán en facilitar el tránsito de datos y de productos del proceso de datos a fin de atender a las necesidades de la VMM de manera oportuna, segura y rentable, asegurando el acceso de todos los Miembros a los datos y productos de conformidad con procedimientos aprobados y dentro de los límites del sistema de la VMM convenido.

Nota: El Sistema brinda también apoyo en materia de telecomunicaciones a otros programas en el marco del SIO, según lo decidido por el Congreso o el Consejo Ejecutivo de la Organización Meteorológica Mundial (OMM), dentro de los límites de sus objetivos principales.

2. Enmendar el párrafo 1.2.1 de la sección 1, parte I, de la manera siguiente

1.2.1 El SMT se organizará de manera que pueda transmitir el volumen de información meteorológica que se requiera dentro de las demoras prescritas como la red principal del SIO y a fin de poder atender las necesidades de los Centros Meteorológicos Mundiales (CMM), los Centros Meteorológicos Nacionales (CMN) y los Centros Meteorológicos Regionales Especializados (CMRE) resultantes de la ejecución de la Vigilancia Meteorológica Mundial.

Insertar una nota después del párrafo 1.2.2c) como sigue:

1.2.2 El SMT se organizará a tres niveles, a saber:

… c) las redes nacionales de telecomunicaciones.

Nota: Los componentes de la RPT que unen los Centros Mundiales del Sistema de Información del SIO se denominan también Red básica del SIO (véase el Manual del Sistema de información de la OMM (OMM-Nº 1060))

3. Enmendar la sección 3 de la parte I de la manera siguiente

3. FUNCIONES Y CARACTERÍSTICAS DE LAS REDES DEL SISTEMA MUNDIAL DE TELECOMUNICACIÓN

3.1 La Red Principal de Telecomunicaciones (RPT)

3.1.1 La Red Principal de Telecomunicaciones es un sistema integrado de circuitos que conecta los Centros Mundiales del Sistema de Información a la Red básica del SIO y a los CRT designados.

Nota: En el adjunto I–2 figuran los nombres de esos centros así como un diagrama en el que se indica cómo se realiza el encaminamiento de los datos a través de la RPT.

3.1.2 La RPT está concebida de manera que el tráfico procedente de cada centro (CMM, CRT designado) se encamine selectivamente hacia el centro o centros de destino. Cada centro de la RPT se encargará de la retransmisión selectiva del tráfico que recibe hacia el circuito o circuitos con los que está conectado.


3.1.3 La RPT tiene como función proporcionar un servicio eficaz y fiable de telecomunicaciones entre los centros designados, a fin de conseguir:

a) el intercambio rápido y seguro de los datos de observación necesarios para atender a las necesidades del Sistema Mundial de Proceso de Datos y de Predicción (SMPDP);

b) el intercambio de información procesada entre CMM, incluido el intercambio de datos recibidos de los satélites meteorológicos;

c) los circuitos regionales, constituidos por circuitos punto a punto, punto a multipunto y multipunto a punto (establecidos por línea terrestre, satélite o radio) que conectan los CMN a los CRT o a otros CMN de la Región;

d) circuitos interregionales, constituidos por circuitos punto a punto (establecidos por línea terrestre, satélite o radio) que interconectan los CRT o CMM con CRT de Regiones diferentes;

Nota: Las responsabilidades de los centros CRT ubicados en la RPT en lo que respecta a la transmisión de datos de observaciones e información procesada figuran en el adjunto I–3.

4. Enmendar el adjunto I-2, parte I, sustituyendo el diagrama existente por el siguiente diagrama (Encaminamiento de los centros regionales de telecomunicaciones del Sistema de información de la OMM)

Adjunto I-2. CONFIGURACIÓN DE LA RED PRINCIPAL DE TELECOMUNICACIONES

Figura 1 Plan de encaminamiento de los centros regionales de telecomunicaciones del Sistema de información de la OMM


5. Enmendar el adjunto I-3, parte I, de la manera siguiente

ADJUNTO I-3. RESPONSABILIDADES DE LOS CENTROS SITUADOS EN LA RED PRINCIPAL DE TELECOMUNICACIONES CON RESPECTO A REGIONALES DE TELECOMUNICACIONES PARA LA TRANSMISIÓN DE DATOS DE OBSERVACIÓN E INFORMACIÓN PROCESADA

1. RESPONSABILIDADES DE LOS CMM Y LOS CRT SITUADOS EN LA RED PRINCIPAL DE TELECOMUNICACIONES CON RESPECTO A LA RECOPILACIÓN, EL INTERCAMBIO Y LA DISTRIBUCIÓN DE DATOS DE OBSERVACIÓN

Las responsabilidades se indican en la tabla siguiente:

[Sustituir la tabla del punto 1 por la tabla de la figura 2 que se muestra a continuación (Centros regionales de telecomunicaciones – Áreas de responsabilidad)]

Región del CRT

Nº de referencia del CRT

Ciudad del CRT (País)(*=CRT/RPT)

CRT principal del CMSI

CRT de apoyo del CMSI

Área de responsabilidad del CRT

1 11 El Cairo* (Egipto)

Casablanca Toulouse Egipto, Sudán, Libia, zonas marítimas adyacentes

1 12 Nairobi* (Kenya)

Offenbach Moscú / Tokio

Kenya, Etiopía, Burundi, Djibouti, Uganda, Rwanda, Somalia, La Reunión, República Unida de Tanzanía, zonas oceánicas adyacentes

1 13 Lusaka (Zambia)

Pretoria Exeter Zambia, Zimbabwe, Malawi


Región del CRT






1 14 Pretoria (Sudáfrica)

Pretoria Exeter Sudáfrica, Angola, Botswana, Lesotho, Madagascar, Malawi, Mozambique, Namibia, Swazilandia, La Reunión, Zimbabwe, y los siguientes centros a través de La Reunión: Antananarivo, Comoras, Mauricio, Seychelles, Isla de Ámsterdam, Kerguelen, zonas oceánicas adyacentes

1 15 Dakar* (Senegal)

Casablanca Toulouse Senegal, Isla Ascensión, Cabo Verde, Islas Canarias, Côte d'Ivoire, Guinea, Guinea Bissau, Liberia, Madeira, Malí, Mauritania, Marruecos, Nigeria, Sierra Leona, Santa Elena, Gambia, zonas oceánicas adyacentes

1 16 Argel* (Argelia) Toulouse Exeter Argelia, Marruecos, Líbano, Túnez, zonas marítimas adyacentes


Región del CRT






1 17 Brazzaville (Congo)

Casablanca Toulouse República del Congo, Camerún, República Centroafricana, Gabón, Guinea Ecuatorial, Santo Tomé y Príncipe, República Democrática del Congo, zonas oceánicas adyacentes

1 18 Niamey (Níger) Casablanca Toulouse Benin, Burkina Faso, Chad, Ghana, Níger, Nigeria, Togo

2 21 Teherán (República Islámica del Irán)

Teherán Por definir República Islámica del Irán, Iraq, Pakistán, Yemen, otros territorios árabes, zonas marítimas y oceánicas adyacentes

2 22 Tashkent (Uzbekistán)

Seúl Moscú Afganistán, Kazajstán, Kirguistán, Tayikistán, Turkmenistán y Uzbekistán

2 23 Novosibirsk (Federación de Rusia)

Moscú Offenbach / Toulouse

Mongolia, Federación de Rusia (en la Región II)


Región del CRT






2 24 Khabarovsk (Federación de Rusia)


República Popular Democrática de Corea, Federación de Rusia (en la Región II), zonas marítimas y oceánicas adyacentes

2 25 Tokio* (Japón) Tokio Beijing / Offenbach / Melbourne

Hong Kong(China), Japón, Macao (China), República de Corea, zonas marítimas adyacentes y del océano Pacífico

2 26 Bangkok (Tailandia)

Tokio Beijing / Offenbach / Melbourne

Camboya, República Democrática Popular Lao, Myanmar, Tailandia, Viet Nam, zonas marítimas y oceánicas adyacentes

2 27 Nueva Delhi* (India)

Nueva Delhi

Por definir Bangladesh, Bhután, India, Maldivas, Myanmar, Nepal, Pakistán, Sri Lanka, zonas marítimas y oceánicas adyacentes

2 28 Beijing* (China) Beijing Tokio China, República Popular Democrática de Corea, Viet Nam, zonas marítimas y oceánicas adyacentes


Región del CRT






2 29 Jeddah* (Arabia Saudita)

Jeddah Por definir Bahrein, Kuwait, Omán, Qatar, Arabia Saudita, Emiratos Árabes Unidos, Yemen, otros territorios árabes, zonas marítimas y oceánicas adyacentes

3 31 Brasilia* (Brasil)

Brasilia Washington / Pretoria

Brasil, Colombia, Ecuador, Guyana francesa, Guyana, Suriname, Venezuela, informes de buques y aeronaves

3 32 Buenos Aires* (Argentina)


Argentina, Bolivia, Chile, Paraguay, Perú, Uruguay, informes de buques y aeronaves

3 33 Maracay (Venezuela)


Colombia, Ecuador, Guyana francesa, Guyana, Suriname, Venezuela, informes de buques y aeronaves


Región del CRT






4 41 Washington* (Estados Unidos de América)

Washington

Brasilia Antigua y Barbuda, Aruba, Bahamas, Barbados, Belice, Territorios Británicos del Caribe, Canadá, Islas Caimán, Colombia, Costa Rica, Cuba, Curasao, Dominica, República Dominicana, El Salvador, Granada, Guatemala, Haití, Honduras, Jamaica, México, Monserrat, Nevis, Nicaragua, Panamá, Saint Kitts, Santa Lucía, San Martín, Trinidad y Tabago, Estados Unidos de América


Región del CRT






5 51 Melbourne* (Australia)

Melbourne Tokio / Seúl Australia y las islas adyacentes, Brunei Darussalam, República Democrática de Timor-Leste, Estados Federados de Micronesia, Fiji, Polinesia Francesa, Indonesia, Kiribati, Malasia, Nueva Caledonia, Papua Nueva Guinea, Filipinas, Samoa, Singapur, Islas Salomón, Tonga, Tuvalu, Vanuatu, Wallis y Futuna

5 52 Wellington (Nueva Zelandia)

Melbourne Tokio / Seúl Nueva Zelandia y las islas adyacentes, Islas Cook, Niue, Pitcairn, Tokelau

6 61 Exeter* (Reino Unido de Gran Bretaña e Irlanda del Norte)

Exeter Toulouse Gibraltar, Groenlandia, Islandia, Irlanda, Países Bajos, Reino Unido, estaciones meteorológicas oceánicas

6 62 Norrköping (Suecia)


Dinamarca, Estonia, Finlandia, Letonia, Lituania, Noruega, Suecia


Región del CRT






6 63 Toulouse* (Francia)

Toulouse Exeter Bélgica, Francia, Luxemburgo, Mónaco, Portugal, España

6 64 Offenbach* (Alemania)


Alemania, Jordania, Israel, Suiza

6 65 Moscú* (Federación de Rusia)


Armenia, Azerbaiyán, Belarús, Georgia, República de Moldova, Federación de Rusia (en la Región VI), Ucrania

6 66 Roma (Italia) Offenbach Moscú / Tokio

Grecia, Italia, Líbano, Malta, Turquía

6 67 Praga* (República Checa)


República Checa, Polonia

6 68 Viena (Austria) Offenbach Moscú / Tokio

Austria, Croacia, Hungría, Eslovaquia, Eslovenia

6 69 Sofía* (Bulgaria)


Albania, Bosnia y Herzegovina, Bulgaria, Chipre, ex República Yugoslava de Macedonia, Rumania, Serbia, República Árabe Siria

Figura 2 - Centros regionales de telecomunicaciones – Áreas de responsabilidad (* se refiere a los centros regionales de telecomunicaciones situados en la Red Principal de Telecomunicaciones)

__________



ENMIENDAS AL ADJUNTO II-15 DEL MANUAL DEL SISTEMA MUNDIAL DE TELECOMUNICACIÓN (OMM-N° 386)

A) Enmiendas propuestas al adjunto II-15

Se proponen las siguientes enmiendas al adjunto II-15 del Manual del Sistema Mundial de Telecomunicación:

1. En el “Prefacio” (p.151):

“En los últimos años se han utilizado En las décadas de 1980 y 1990 se utilizaron varios protocolos, entre ellos el X.25.”

“Se han realizado considerables esfuerzos por definir el marco de aplicación de los protocolos TCP/IP al SMT y por lograr una transición ordenada a partir de la interconexión de sistemas abiertos (OSI)/X.25, protocolo original del SMT. Además, queda entendido que los protocolos TCP/IP constituirán constituyen actualmente la base de todas las nuevas funciones de telecomunicación implementadas en apoyo del Sistema de información de la OMM (SIO).”

2. En “Introducción” / “Perspectiva histórica” (p. 151):

“En la actualidad, el SMT se utiliza principalmente para dar soporte a la aplicación de conmutación de mensajes mediante el intercambio de mensajes en formato OMM. Este intercambio se efectúa mediante:

a) protocolos TCP/IP,

b) un servicio de transporte OSI limitado basado en una conectividad X.25 punto a punto,

y se completa con difusiones.”

3. En “Introducción” / “Finalidad del presente adjunto” (p. 152):

“En el presente adjunto se describen los aspectos de la aplicación de los protocolos TCP/IP específicamente aplicables al SMT en respuesta a nuevas necesidades, así como el intercambio habitual de datos que desde hace ya tiempo realizan los sistemas de conmutación de mensajes. Al elaborarse el presente adjunto se tuvo en cuenta la evolución técnica del SMT a partir de una red X.25, así como el principio de que los centros han de seguir siendo autónomos en la medida de lo posible. Se reconoce que el ritmo de implantación de nuevos sistemas vendrá determinado por los Miembros, en función de los recursos de que dispongan y de sus prioridades relativas, aunque al mismo tiempo se espera lograr la nueva funcionalidad del SIO fundamentalmente a través de los protocolos TCP/IP.”

4. En “Evolución del SMT” (p. 153):

“El estándar X.25 de la ISO/UIT fue adoptado por la OMM a comienzos del decenio de 1980 para facilitar el intercambio de datos y productos codificados en claves binarias de la OMM (GRIB, BUFR, etc.) y como base para la introducción de aplicaciones OSI de nivel superior. Aunque por aquel entonces la OSI estaba considerada como la dirección estratégica hacia la que evolucionarían las comunicaciones de datos, la situación ha cambiado. En la actualidad, es ya indiscutible que los protocolos TCP/IP son los más aceptados y extendidos para el intercambio de datos.”

5. En “MÉTODOS DE INTERCAMBIO DE DATOS EN EL SMT – Introducción” (p. 164):


“Existen tres métodos de intercambio de datos definidos para el SMT. Los dos primeros están destinados al intercambio de mensajes SMT tradicionales. El tercero se utiliza para el intercambio de otros tipos de datos.

FTP y SFTP son los dos métodos de intercambio de datos que pueden utilizarse en el SMT.

Para los mensajes SMT tradicionales (los cifrados en la forma TTAAii CCCC), esas dos normas están basadas en:

a) sockets TCP/IP;

b) FTP.

Los centros podrán escoger entre esas dos normas Se insta a los centros a que escojan los métodos FTP o SFTP mediante un acuerdo bilateral. Se dará preferencia al método SFTP sobre Internet.

Es posible intercambiar también otros datos en el SMT utilizando una norma diferente basada en FTP.”

6. En “MÉTODOS DE INTERCAMBIO DE DATOS EN EL SMT” (p. 164-166):

SCM basados en sockets TCP

La norma de sockets TCP implica el establecimiento de una conexión del emisor al receptor, y el envío de los mensajes SMT precedidos de dos campos de control. El primer campo contiene la longitud del mensaje, y el segundo es un campo de 2 caracteres que indica el tipo de mensaje (binario, alfanumérico o fax). El tercer campo es el mensaje SMT propiamente dicho, incorporado en una envolvente estándar SOH/ETX del SMT. El centro receptor utiliza la longitud del mensaje para determinar el comienzo y final de cada mensaje entrante.

El protocolo de sockets TCP del SMT no garantiza una entrega de extremo a extremo, y es posible que se pierdan datos si el enlace o uno de los sistemas de conmutación de mensajes falla.

La estructura completa aparece ilustrada en la figura 6. Obsérvese que la longitud del mensaje no incluye la longitud de los dos primeros campos (longitud y tipo de mensaje). El mensaje deberá tener siempre una longitud de ocho caracteres y contendrá los ceros iniciales que sean necesarios. El campo de tipo de mensaje debería estar codificado mediante los caracteres ASCII siguientes: BI para mensajes binarios, AN para alfanuméricos, y FX para facsímil.

<FIGURA 6>

Las reglas para el intercambio de datos mediante socket TCP/IP pueden resumirse como sigue:

1. Todas las nuevas conexiones deberán comenzar a partir de un nuevo mensaje.

2. Todo mensaje irá precedido de un campo de longitud de mensaje de ocho caracteres ASCII y de un campo de tipo de mensaje de dos caracteres ASCII.

3. La longitud del mensaje se contará desde SOH hasta ETX inclusive, y deberá contener los ceros iniciales necesarios.

4. El tipo de mensaje deberá estar codificado como BI si es binario, AN si es alfanumérico, o FX si es facsímil.

5. Los centros receptores comprobarán la sincronización como sigue:

• Se comprobará que los 8 primeros caracteres sean numéricos ASCII.


• Se comprobará que los caracteres 9º y 10º sean BI, AN o FX.

• Se comprobará que el 11º carácter sea SOH.

• Se comprobará que el último carácter sea ETX.

6. Si se perdiera la sincronización, el receptor cortará la conexión mediante la secuencia siguiente de primitivas de usuario TCP:

• shutdown (para asegurarse de que todos los datos del buffer de envío TCP han sido transferidos);

• close.

7. Se recomienda utilizar un socket diferente para los mensajes ASCII y binarios, y una conexión diferente para el envío y la recepción. El emisor debería tener siempre la responsabilidad de establecer la conexión.

8. Una vez establecida una conexión, ha de ser mantenida.

9. Si fuera necesario cerrar un socket, el procedimiento constará de los siguientes pasos:

• shutdown (para asegurarse de que todos los datos del buffer de envío TCP han sido transferidos);

• close.

10. Este procedimiento debería utilizarse también para cerrar un SCM.

11. Si el receptor recibe una nueva solicitud imprevista de conexión en un puerto para el que hay un socket establecido, debería cerrarse el antiguo socket y aceptar el nuevo.

12. Los números de servicio/puerto TCP/IP para estas conexiones se decidirán mediante acuerdo bilateral. Debería evitarse el uso de puertos reservados (1 a 1023). Se recomienda utilizar puertos por encima del 10000.

13. Para reducir el volumen de datos que se pierde cuando falla una conexión establecida, puede ajustarse el tamaño de los buffers de envío y de recepción TCP. El tamaño de buffer recomendado es 4 KB, aunque este valor puede acordarse bilateralmente.

14. A fin de poder detectar la pérdida de un mensaje, es obligatorio utilizar el número de secuencia de canal (CSN). Cuando se utilice el CSN para comprobar si se han perdido mensajes, deberían utilizarse los procedimientos de solicitud/repetición de la OMM para recuperarlos. Podría ser útil automatizar este mecanismo para evitar las demoras causadas por la intervención manual. Para reducir a un mínimo la pérdida de datos, se recomienda rotundamente que los centros implementen un CSN de 5 caracteres en el futuro.

15. El número de secuencia de canal 000 (o el 00000, respectivamente) debería indicar una inicialización, y no debería dar lugar a solicitudes de retransmisión.

7. En “MÉTODOS DE INTERCAMBIO DE DATOS EN EL SMT” (p. 166)

“Procedimientos SFTP o FTP y convención para la denominación de archivos

Introducción

El protocolo de transferencia de archivos SFTP es un protocolo de transferencia de archivos seguro basado en el protocolo SSH (Secure Shell). No hay una petición de comentarios (RFC)


oficial estándar. A pesar de ello, el protocolo SSH y, por lo tanto, el protocolo SFTP es ahora fácilmente accesible en Internet y muy utilizado.

El protocolo de transferencia de archivos (FTP) constituye un método conveniente y fiable para el intercambio de archivos, especialmente los de gran tamaño. Este protocolo está definido en RFC 959.

Los principales temas que han de considerarse son:

1. los procedimientos para recopilar mensajes en archivos a fin de minimizar elementos SFTP y FTP no esenciales para mensajes cortos (aplicable únicamente a los tipos de mensaje existentes);

2. las convenciones de denominación de archivos para tipos de mensaje existentes (AHL existente);

3. las convenciones generales de denominación de archivos;

4. la redenominación de archivos;

5. la utilización de directorios;

6. los nombres de cuenta y contraseñas;

7. las sesiones SFTP o FTP;

8. las necesidades SFTP o FTP locales;

9. la compresión de archivos.

Recopilación de mensajes en archivos

Uno de los problemas que plantea la utilización de FTP para enviar mensajes SMT de tipo tradicional es el contenido no esencial cuando cada uno de los mensajes se envía en un archivo separado. Para resolver este problema, los Los mensajes múltiples contenidos en la envolvente estándar de mensaje SMT deberían podrían incluirse en un mismo archivo, de acuerdo con las reglas que se indican a continuación. Este método de recopilación de múltiples mensajes es aplicable solo a los mensajes para los que se han asignado AHL.”

8. En “MÉTODOS DE INTERCAMBIO DE DATOS EN EL SMT” (p. 173)

Utilización de directorios

Algunos centros receptores podrían desear que los archivos se coloquen en subdirectorios determinados. A este respecto, debería imponerse la limitación de que solo la totalidad de los archivos de un mismo tipo sean enviados a un mismo directorio. Se recomienda utilizar un directorio diferente para cada sistema anfitrión que inicie sesiones SFTP y FTP, para evitar la posibilidad de que haya nombres de archivo duplicados.

Nombres de cuenta y contraseñas

Al utilizar el STFT o el FTP, el emisor se conecta a una máquina distante utilizando un nombre de cuenta y una contraseña dados. El centro receptor define el nombre de cuenta y la contraseña. Este procedimiento puede afectar a la seguridad de los centros, por lo que conviene adoptar precauciones.

En cualquier caso, deberían aplicarse las reglas generales siguientes:

a) El centro receptor define la cuenta de usuario y la contraseña del centro emisor.


b) Se puede utilizar un FTP anónimo o crear una cuenta específica. (Si se utiliza un FTP anónimo, cada centro emisor deberá tener su propio subdirectorio en el servidor FTP.)

Las sesiones SFTP también pueden autenticarse utilizando claves asimétricas. Los Servicios Meteorológicos e Hidrológicos Nacionales pueden escoger entre utilizar usuario y contraseña o claves asimétricas.

Sesiones SFTP o FTP

A fin de limitar la carga de los sistemas de envío y recepción, no debería existir al mismo tiempo más de una sesión SFTP o FTP por tipo de archivo. Si, por ejemplo, el Centro A desea enviar al Centro B dos archivos de un mismo tipo (por ejemplo, .ua), el segundo archivo no deberá ser enviado hasta que el primero haya terminado de llegar. Los centros deberían limitar a un máximo de cinco el número de sesiones simultáneas con un centro determinado.

El temporizador de inactividad para cerrar la sesión SFTP o FTP debería fijarse en un valor comprendido entre el tiempo de corte de recopilación de mensajes (máximo, 60 segundos) y un máximo de 3 minutos.

A fin de reducir al mínimo el contenido no esencial, el centro emisor deberá mantener abierta la sesión SFTP o FTP durante 10 minutos como mínimo, o hasta que se alcance el tiempo límite de inactividad (sujeto a acuerdo bilateral).

Necesidades SFTP o FTP locales

Todos los centros emisores tendrán que prever la posibilidad de incluir comandos FTP “estáticos” adicionales en los comandos FTP que emitan. Así, por ejemplo, en algunos centros que utilizan el sistema operativo MVS podría ser necesario incluir comandos “SITE” para definir las longitudes de registro y de bloque. Los centros deberían soportar comandos FTP conforme a lo especificado en RFC 959, a menos que algunos queden excluidos en virtud de un acuerdo bilateral. Podría ser también necesario acordar bilateralmente algunos procedimientos y comandos

Los centros receptores tienen la responsabilidad de borrar los archivos que ya han procesado.

A fin de cumplir el requisito de entrega máxima en 2 minutos de los mensajes de aviso, los centros que reciban archivos por SFTP o FTP procurarán recoger y procesar los archivos entrantes antes de que transcurran 15 segundos desde su recepción.

--------------------

B) Actualización de la tabla 6 “Valores de compression aceptados”, adjunto II-15 del Manual del Sistema Mundial de Telecomunicación

El Equipo de expertos sobre las técnicas y la estructura de comunicación del SIO y el SMT señaló que el Equipo de expertos interprogramas sobre representación, mantenimiento y control de datos había aprobado los cambios y había estado de acuerdo en incluir la siguiente actualización en el adjunto II-15 del Manual del Sistema Mundial de Telecomunicación:

Se enmendará la tabla 6 “Valores de compression aceptados” del ADJUNTO II-15 (p. 170) para introducir los nuevos valores de compression aceptados y la compresión “Z” se marcará como “relegada”.

Compresión Significado

Z RELEGADA El archivo ha sido comprimido mediante la técnica COMPRESS de


zip

gz

bz2

xz

Unix

El archivo ha sido comprimido mediante la técnica zip de PKWare

El archivo ha sido comprimido mediante la técnica gzip de Unix

El archivo ha sido comprimido mediante la técnica bzip2 de Unix.

El archivo ha sido comprimido mediante la técnica xz

C) Actualización de la tabla 3. “Valores de pflag aceptados”

Se actualizará el ADJUNTO II-15 para incluir la capacidad de comprimir/empaquetar los archivos antes de la transferencia (p. 168). Introducir los ejemplos y las notas de la manera siguiente:

Tabla 3. Valores de pflag aceptados

pflag Significado

T El campo productidentifier se descodificará como indicativo de datos T1T2A1A2ii estándar. (Los indicativos de datos estándar de la OMM figuran en el adjunto II-5.)

A El campo productidentifier se descodificará como encabezamiento abreviado estándar, en su caso con el bloque BBB, y descartando los espacios, por ejemplo: T1T2A1A2iiCCCCYYGGgg[BBB].

W Indicativo de producto OMM

Z Indicativo de producto local del centro originador

X Se deberán extraer varios ficheros SMT válidos en función del tipo de archivo.

TM El campo productidentifier será descodificado como indicativo de datos T1T2A1A2ii estándar (los indicativos de datos estándar de la OMM figuran en el adjunto II-5). El archivo contendrá los metadatos correspondientes al archivo “T” conexo.

AM El campo productidentifier será descodificado como encabezamiento abreviado estándar, en su caso con el bloque BBB, y descartando los espacios, por ejemplo: T1T2A1A2iiCCCCYYGGgg[BBB]. El archivo contendrá los metadatos correspondientes al archivo “A” conexo.

WM Identificador de producto OMM. El archivo contendrá los metadatos correspondientes al archivo “W” conexo.

ZM Identificador de producto local del centro originador. El archivo contendrá los metadatos correspondientes al archivo “Z” conexo.

Ejemplo de archivo:

X_fr-meteofrance-Toulouse_C_LFPW_20060913030000.tar.xz

Este podría contener los siguientes archivos una vez realizada la extracción:• T_PGBE07_C_KWBC_20020610180000_D241_SIG_WEATHER_250-600_VT_06Z.tif • W_fr-meteofrance-Toulouse,SYNOP,MAIN+HOURS,,RRA_C_LFPW_20060913030000.txt • LFPW00000123.b


• LFPW00000124.f • LFPW00000125.b

[Añadir notas:]

a) La utilización de los ficheros de archivo para el intercambio por FTP se realiza mediante acuerdos bilaterales entre los centros. Todos los nuevos CMSI deberán disponer de esa funcionalidad desde el principio de 2018 y cualquier CMSI existente antes de finales de 2020.

b) Tan solo para los ficheros comprimidos con el valor pflag X se permiten las extensiones de formato de archivo tar, tar.gz, tar.xz and .zip

__________


Annex 4 to draft Recommendation 3.5/1 (CBS-16)

AMEND GUIDE TO INFORMATION TECHNOLOGY SECURITY (WMO-No. 1115)

Make the following amendments be made to the Guide to Information Technology Security (WMO-No. 1115)

(See http://wis.wmo.int/file=2479 for authors’ full text track changes)

1. Under Revision History include:

2016-April – ET-CTS, document review

2. Under 1. Executive Summary

(Paragraph 1)

The quality of our work, our research and our services for supporting the health and safety of humans depends on the exchange of meteorological and environmental data, and on discussions that occur within the WMO our scientific community.

(Paragraph 3)

However, in parallel to these positive changes in the way our community works, an increasing number of threats are prevalent throughout the whole Internet, and …

(Paragraph 5)

For example, it would potentially only take minutes for a newly purchased computer system to become infected with some form of electronic virus if it was installed on connected to the Internet without …

(Paragraph 8)

… It should help to act as an aid to understanding the basic concepts and principles of ITS, …

(Paragraph 9)

– … approach to all ITS matters

– Building a zoned network architecture that will provide resilience against attempts to illegally penetrate compromise systems, networks and hosts. In this context, a zone is a logical area within a networking environment with a defined level of network security

– Monitoring external connections in order to detect any abnormal access or activity

– Regularly applying security patches to critical systems as they become available

– Ensuring that access control mechanisms are in place, commensurate with the system being protected, and M m anaging them with diligence. care the user access codes and passwords

– reinforcing best security and cultural practices across Organisations through continual security education

The complete list as defined in the International Standards Organization (ISO) / International Electrotechnical Commission (IEC) information security standard can be found at

http://wis.wmo.int/file=2481


http://en.wikipedia.org/wiki/ISO/IEC_27002. Another helpful reference is http://www.itgovernance.co.uk/bs7799.aspx.

3. Under 2. Definition of Information Technology Security

The purpose of Information Technology Security (ITS) is to help an organization fulfil its mission by protecting its IT resources, which also include observation systems, and through that, its assets. These assets must be properly identified so that adequate security requirements can be defined.

Adequate security requirements can be defined using the following steps:

1. Identifying the assets

2. Identifying the proper security criteria with, for each criterion, a proper scale (cf. §2.3)

3. Identifying the assets’ security needs, according to the defined criteria

4. conducting a risk analysis (some risks described in § 2.2)

5. Identifying the security techniques and procedures to consider (cf. §2.4)

Additional information regarding the information security standard can be found at http://en.wikipedia.org/wiki/ISO/IEC_27002, and http://en.wikipedia.org/wiki/ISO/IEC_27001 and in section five of this document.

The next four sections briefly mention some of the tasks necessary tasks to implement ITS…

4. Under 2.1 Protecting systems against potential failures

All Information Technology (IT) resources play a part, which must be correctly understood, in permitting an organization to deliver services according to its mission. Any failure in these IT resources can then affect the capability to deliver these services.

Moreover, most some organizations have dedicated links with partners. By default, these partner links should be considered similarly to as unsecure as any other public link (such as a the connection to the Internet). They could be used to propagate security threats incidents between organizations. In the best-case scenario, these could damage reputation, and, in the worst-case scenario, generate legal proceedings.

Thus, ITS is concerned …

5. Under 2.2 Malicious versus non-malicious

… For example, malicious activities can include fraud and theft, internal or external hackers, malicious codes such as viruses or spyware, espionage, etc. …

6. Under 2.4 Security techniques and procedures to consider

Once an organization has properly identified its ITS requirements, prevention measures are set up to prevent or restrict an error, omission or unauthorized intrusion measures are implemented to technically and procedurally deliver against them.

Monitoring and reporting should give the organization some proper visibility of its information system. They It must be defined so that a security incident can be quickly detected, and its origin properly identified, and for this to act as an enabler to a complementary process that would limit the threat boundary (such that it is prevented from doing further damage to connected systems/data).


Predefined I i ncident handling and disaster recovery procedures are helpful in minimizing essential to minimize the impact of an ITS-linked incident event within an organization, by reacting quickly and in a proper manner to the incident, and by being able to recover the essential elements impacted by the incident.

Once the incident is over, it must should be analysed so that prevention measures can be reviewed potential lessons can be learned if necessary.

7. Under 3.1 Reasons for threats

The motivations Motives can be deliberate or accidental.

8. Under 3.1.3 Playful or exploration to 3.2.3 Malicious hacking

Another kind of motivation is curiosity, boredom, game or challenge. Many famous governmental institutions have been impacted hit by such motivated attacks, degrading their reputation.

3.1.4 Accident

The last category is human or physical accident or oversight. It can take many forms and touch any part of the information system (network, hardware, and software, procedural), and can be prevented mitigated by adequate disaster recovery procedures and training, such as implementing system redundancy and automatic failover procedures, being aware of public visibility, or delivering regular training.

9. Under 3.2 Common threats

3.2 Common threats

A very resourceful link for this topic is https://www.sans.org/critical-security-controls http://www.sans.org/top-cyber-security-risks/.

3.2.1 Malicious codes: viruses, ransomware, worms and Trojans horses

A virus is a destructive computer program that spreads from computer to computer using a range of methods, including infecting portable storage (e.g. USB), infected web pages floppy disks and other programs. Viruses typically often attach themselves to a program and modify it so that the virus code runs when the program is first started. The infected program typically appears to runs normally, but the virus code then infects other programs whenever it can.

A worm is a special type of virus that does not attach itself to programs, but rather spreads via other methods such as e-mail.

A Trojanhorse (or backdoor) is a program that performs the desired task, but also includes unexpected functions, such as allowing remote connection to the infected computer or sending information.

All these codes have the potential to disrupt services, destroy information, use resources for their own good, or any other function that the originator of the code may wish to implement.

3.2.2 Denial of service

A denial-of-service attack is characterized by an attempt to prevent legitimate users of a service from using that service. These attacks can be deliberate or accidental, such as abusive use of storage, network and supercomputing resources. They can also be from distributed (and therefore difficult to block) sources, using networks of compromised hosts called a “botnet”.

10. Under 3.3.1 Hacking systems …


All these components, if not kept up to date regarding security holes, or if not properly configured, can easily be used by a threat agent (human, such as malicious hackers, or non-human, such as viruses) to compromise the system. If the security hole is not known to the vendor it is known as a zero-day vulnerability. Patches should be applied when they become available.

Specific tools exist, used by security staff as well as malicious hackers, to identify both security holes and configuration weaknesses of a system.

11. Under 3.3.4 Spying …

One of the most dangerous forms of spying is a class of software called keyloggers. Once installed on a computer, these systems can collect every keystroke, mouse movement and screen update on a computer, thus allowing a hacker to obtain all privileged information before it is encrypted or after it is decoded. Keyloggers can also be of the hardware variety, often placed in-line on USB ports, and can use their own wireless connectivity to report what they gather back to an off-site system.

3.3.5 Root or Domain Controller access

Hackers try to get access to the most privileged user or account in order to gain control of the entire network. Avoid keeping the passwords hard coded in the software or saved in flat files or in spreadsheets.

3.3.6 Wireless LAN Networks

Wifi has become an accepted method of connection of mobile devices. Mobile devices connect to a wifi access point to access IP services. These services can be replicated by "imposter" systems to look like official wifi services, but can act very differently. For example, when they are used to access the Internet they can locally show a Web page to be secure when accessed, but the secure access is only to the "imposter" device, not the end website. Users information including their passwords and keys can then be captured in the open, and used to steal personal information and access services.

Users are less likely to be vulnerable if they are accessing internet services through a VPN tunnel to their home organization. The use of split tunnelling (where Internet services are accessed locally) increases the risk and is not recommended for Corporate use.

It is possible for official organizations wifi to detect and suppress these "imposter" access points, but this is unlikely where you do not control the environment. In a public space be vigilant for wifi services which have multiple similar names, or if in doubt, ask someone in charge which service to use.

12. Under 4 Impacts of Threats and Security Events

Although it can be difficult to predict exactly what the impacts can be, the following are key potential impacts, which can be used to prepare security plans and contingency plans. Understanding the potential impacts is also important in justifying the funding for security measures, as the cost of repair, loss of business, loss of reputation and even loss of life often far exceed the cost of defence mitigation measures.

It should also be noted that although some events may seem to be low impact at first, they could be of major importance to an organization at a later date, since many events are just part of a set-up process for later events. In addition, because all organizations will be interconnected, these types of events can be set-ups for attacks in other organizations. In this respect, it is important to note our responsibility to the community of interconnected machines systems.

… 4.1 System and service impacts …


(c) System or component of system or data destroyed: The events cause not only the systems and services not to be available for a period of time, but cause the destruction of resources. Typically, this can be the destruction of data on hard disk drives storage media, or stored in the database. Some viruses have been demonstrated to harm hardware by putting it in states that it was not designed to be in used for. These problems waste much time, but also require system components to be either replaced or reinitialized. There is often an important cost associated with these repairs.

(e) System used to compromise others: The events would compromise an organization’s systems in a way that is not detected, and may be left unused for a long time. However, these components can be used to compromise other systems. Although the impact on a given organization may seem negligible, harm to other organizations is possible. Furthermore, hackers often use such techniques to hide themselves behind several layers of obscurity as a of apparently unnecessary hops disguise. These layers render troubleshooting very difficult and provide much hiding space for illicit components. An organization could be falsely accused of being the source of trouble because of this technique.

4.2 Administrative, legal and reputation impacts

In addition to the obvious system and service impacts, all security events can also cause administrative, legal and reputation impacts. By being connected to the Internet, all organizations need to act as good corporate citizens. They must mitigate the problems of security and ensure they are not the cause of problems to others. Failure to do so may eventually lead to legal action. It is also obvious that bad information and poor service will certainly have administrative impacts, as well as the loss of reputation impacts. This is particularly important in the weather business, where state agencies have an important responsibility for the health and safety of their citizens.

The perception that a member in the GTS community may be compromised can lead to a series of restrictions or concerns that this may be a threat to connected agencies. Members may isolate one another until further information on the issue is sought. This can take some time as this may involve the national intelligence counterparts. During this period the exchange of critical meteorological information across the world may be disrupted reducing the quality of the services offered.

13. Under 5 Information technology security processes

5 INFORMATION TECHNOLOGY SECURITY PROCESSES

The ISO 27000 family of standards helps organizations to keep their information assets secure. ISO/IEC 27001 is the best known standard in the family providing requirements for an information security management system.

These request are described below in more detail.

5.1 …

Security criteria that are important for the organization must then be defined, so that each asset’s security needs can be expressed regarding these criteria. The most common ones are availability, integrity and confidentiality.

14. Under 6 Information Technology Security Best Practices

6.1 IT Network and system security

IT system security in this context includes application, operating system, data, and network security. The following paragraphs refer to network and operating system security only. Application and data security will be addressed by an update of this document.


…

Integrity

System integrity is assured through network and system protection, host-based or network-based intrusion detection/prevention systems and an appropriate backup/restore strategy. Data integrity can be assured through cryptographic measures such as hash and signing algorithms.

Confidentiality

Confidentiality is achieved through organization, network, and system, protection and cryptographic protection measures.

Accountability

Accountability is achieved through logging of system access and authorization wherever possible.

A key measure for all three security criteria is network and system protection. A key technology for network protection is using firewall systems. The most common use application for firewall systems is a central firewall between the internal network and the Internet based on a proper zoned design. However, depending on the complexity of the internal network, distributed firewall systems should be put in place to protect sensitive internal network zones and systems, for example, databases and servers running critical services, from more dangerous parts, for example, network zones connecting user personal computers (PCs) and workstations (see section 6.2). Network protection can also be improved by introducing an intrusion detection/prevention system (IDS/IPS) to monitor the network traffic at certain points and to detect unwanted or suspicious traffic according to the security policy (section 6.5).

System protection is more complex. The following measures have to be taken:

(a) Access control: Make sure that only authorized personnel have both physical and electronic access to a system. In addition, authentication has to be as strong as possible of appropriate strength (appropriate password policy, certificate- or token-based authentication). Finally, logging is important to trace user activity, especially on mission critical systems. Hence, group-based accounts should be avoided wherever possible (where a single account is used and the password shared between users).

(b) Minimize services: Disable all services and processes that are not necessary for system operation and service offerings. Run only one single service on critical systems such as Domain Name System (DNS) servers, web servers, etc. Do not combine multiple services whenever possible.

...

(e) Diversification and redundancy: Make mission critical services, such as DNS servers, customer-related web and File Transfer Protocol (ftp) servers, database servers, e-mail relays, etc., redundant. Make sure that these redundant servers and gateways are physically separated to protect the overall system from fire, flooding, etc.

6.2 …

Virtual networks can be set up on top of physical networks or other virtual networks. There are numerous types of virtual networks. The most popular are:

– VLANs: Virtual LANs are used to segment a LAN-based Intranet into different network zones; a VLAN is built on top of a LAN and is based upon Ethernet packet tagging according to the Institute of Electrical and Electronics Engineers (IEEE) standard 802.1q.


– VPLS: Virtual Private LAN Service is a way to provide Ethernet-based multipoint to multipoint communication over IP or MPLS networks.

…

Be careful Care should be taken with encrypted virtual networks such as IPSec-based VPNs that are set up in tunnel mode versus VPNs in transport mode, which make use of data signing only. Because data are encrypted, virus scanners, intrusion detection/prevention systems and other centralized security measures may do not work. …

6.2.1 …

… while a PC is always at risk of Internet worms, Trojan horses and other malicious software.

The host (or PC) in the internal network must strictly follow the security policy of the corresponding network zone, and invalid external connection detection software should be installed in the host which could access the critical IT resource. The LAN segments that connected most critical IT resource or the sensitive data should be physically isolated by the local law.

To protect the disjunctive network segments from each other, they should be interconnected through appropriate firewall separation systems.

The security of an Ethernet LAN or LAN segment can be increased by using ISO/OSI (Open Systems Interconnection) layer 2 switching technology instead of broadcast media, so that traffic from a host A to another host B cannot be sniffed by a third-party host C. However, layer 2 switching cannot avert the so-called Address Resolution Protocol (ARP) spoofing. Additional security measures, such as Port Based Network Access Control in conjunction with the use of host certificates, either based on registered hardware addresses or as defined in IEEE standard 802.1x have to be taken into consideration to protect LANs from such attacks. Port-based access control makes sure that hosts which have not been registered cannot be connected to the network.

6.2.2 Wide Area Networks

A WAN interconnects a number of local networks that can be LANs or other WANs, for example, Metropolitan Area Networks. In this context, a VPN can also be seen as a WAN.

Typically, WANs are public or semi-private networks that are used by different companies, public offices or even private people. Furthermore, a WAN has to carry multiple protocols mostly making it impossible to apply certain filters that comply with the demands of all users.

Therefore, WAN security can mostly be considered low. Measures have to be taken to protect a private Intranet against public WANs. These measures are referred to as firewalls or firewall systems.

6.2.32 Wireless Local Area Networks

Securing Wireless LANs (WLANs) are very critical with is critical in regards to availability, integrity and confidentiality:

– Availability: …

– Integrity and confidentiality: Cryptographic measures have to be taken to guarantee data integrity and data confidentiality, if required. In particular, authentication data such as user names, passwords and token codes have to be encrypted to avert scanning and spoofing. One such method could be using IEEE 802.1x.


The following measures have to be taken to protect WLANs and other network zones that are connected to WLANs:

– WLAN footprint: Make the reception area of a WLAN (footprint) as small as possible match only the area of intended coverage. Make sure that WLAN radio cannot be received outside desired borders. Use a WLAN radio scanner to verify.

– Radio shielding: ...

– Encryption: Use encryption on WLANs. Choose the best available encryption algorithm and change the default settings before activating WLANs. Do not rely on standard encryption (Wireless Application Protocol (WAP), IEEE 802.11i) for mission critical WLANs. For user authentication and data encryption, …

– …

– Intrusion detection: If necessary, install an IDS/IPS for additional security. Note that an IDS/IPS does not work well for encrypted network zones. However, the IDS/IPS can monitor communication relations and can generate alarms in case of illegal activity up to ISO/OSI layer 4, for example, port scans.

– Protecting access: Mechanism to protect the Wireless Network to unauthorized access must be used. This includes, for example, 802.1x or WPA2.

6.2.4 3 Firewall systems

Firewalls can be divided into two major groups:

– Packet filters

– Application Layer and rule based (also known Next Generation firewalls) Gateways

Packet filters control network traffic …

…

While a firewall always reassembles incoming IP packets to prevent attacks caused by fragmentation, access lists on routers do not reassemble fragmented packets. Therefore, access lists cannot always be considered as a substitute for a firewall.!

6.3 Remote access

Remote access to network resources is one of the most critical applications with regards to network security. Remote-access systems can be:

– Plain Old Telephone Systems, Public Switched Telephone Networks or Integrated Service Data Networks dial-in servers

– Secured Internet access (IPSec- or SSL-based VPN gateways)

– Wireless access servers (for example, Bluetooth)

There are four items that have to be taken into consideration when designing and operating remote access:

(a) Network architecture: …

(b) User authentication: In particular, for remote-access systems, proper user authentication is essential for overall network security. Strong authentication mechanisms such


as certificate- or token-based or multi-factor methods are preferred over weak, password-based methods.

(c) User authorization: Make sure that even authenticated users will not obtain access to all systems. Authorization rules have to be in place to limit access to systems that the user is authorized for. For easy maintenance, authorization should be based on groups rather than on per-user rights. A user may be a member of several groups, granting the individual all the rights of each group. The host, that is being by an authorized user to get access to an internal system, should meet the security requirement.

(d) Logging and accounting: …

6.4 Server access and security

…

– The servers are well patched against all known security holes. Make sure that the latest patches have been applied. Verify the p Patches should be before verified in accordance with change and configuration management processes prior to being installed ing them (especially on mission critical systems).!

In addition to authorization mechanisms, …

… Systems that serve anonymous users should be separated from pre-authorized systems that store confidential data. They should be located in separate firewall zones. Never operate both anonymous and pre-authorized services on one single machine.!

…

6.4.1 File system authorization rules

Both anonymous and pre-authorized systems require strict authorization rules. By default, only read access should be allowed. Write access should only be allowed when required. Systems with write access should have dedicated directories to store the data and to scan for viruses and malicious code before making them available to internal resources or users.

Finally, make sure that directory and file visibility rules are in place. Hide as much information as possible and only make information visible to the remote user required to successfully use the service offered. This also comprises directory and file access rules. Make sure that private files and directories cannot be accessed through fraudulent user behaviour such as directory traversal attacks.

Sometimes, it might be required to only accept signed data to verify data integrity. Unsigned data …

6.5.2 Developing a policy

…

Finally, policies should be approved and signed by an appropriate a high authority in the organization. Again, since security is the matter of several (if not all) components of an organization, only a high such an authority will ensure consistency in approach and in implementation.

…

6.8.2 New system installation and change management


All new systems or new system components should be introduced in the production environment through a predefined installation procedure. This procedure should include at least the following steps:

– Suppress all the accounts that do not have passwords

– Back up all configuration files

– Ensure software is up to date according to the organizations configuration and version control processes, and keep a list of components and version numbers

– Suppress network services that are not necessary

– Configure and install a logging system for all important system activities

– Use shadow passwords and limit validity of passwords

All changes should be tracked to control the system components and be capable of tracing unwanted changes.

6.8.3 Installation of security patches

Follow the security advisories from the Computer Emergency Response Team (CERT) (for example, http://www.us-cert.gov, http://www.dfn-cert.de, https://www.cert.be or http://www.cert.ssi.gouv.fr) and install patches as soon as they are available.

6.8.4 User account management

– All accounts must belong to a specific user.

– Each user should read and understand the organization’s security policy.

– End-users’ User accounts that are unused for a period of time (3 months) should be deactivated.

– Password crackers should be run on a regular basis to identify easily cracked passwords and notify the users to change these passwords to more difficult ones. However, be aware to pay attention to possible legal issues! Best practise is to inform the users about regular password checks and let them individually sign a declaration of agreement, for example, in terms of a common IT user policy before running any password cracking tools.

– A password policy should be defined, which outlines the requirements for password complexity, strength, and duration; this policy should be known by all users. Passwords must be changed on a regular basis (at least every 3 months).

– Remote-access users should use one-time password systems to eliminate the possibility of password capture by illicit users.

– Users should be informed of what constitutes a good password.

6.8.5 Backup/restore procedures and regular testing …

6.8.6 Detection procedures

Several detection procedures can be put in place to monitor system activity and possible illicit or unwanted activity. These procedures should be 24/7 and can include intrusion detection and prevention, abnormal system activity detection, vulnerability scanning, loss of system or loss of data procedures.


6.8.6.1 Protection from viruses malicious code

Real-time anti-virus systems should be installed and applied on all operational computer equipment where appropriate . Whole-of-server scans should be run on a daily basis. Anti-virus software should be configured in real-time mode to ensure any infections are identified and cleaned immediately upon detection.

A separate server or computer should be configured to sit inside the organization’s firewall in real-time mode. This server should be configured with appropriate software to check for viruses malicious code. If a virus such code is detected and all incoming and outgoing e-mail attachments can be cleaned, then the message can be distributed. If attachments cannot be cleaned, then the message should be blocked.

Anti-virus software should be regularly updated with new definition files. Anti-virus software should be regularly reviewed. It may be necessary to use more than one type of scanning software to ensure that maximum protection is provided for all information platforms and environments. Organizations should ensure that virus protection and recovery strategies are included in risk-management and business continuity plans.

Typical controls to protect against malicious use technology, policies and procedures, and training, applied in a layered manner from perimeters inwards to hosts and data. They should be applied at the host, network, and user level.

6.8.6.2 User education

…

6.8.8 Security information and event management

It is recommended to implement a solution capable to monitor, evaluate and correlate events related to security issues. This type of solution, known as SIEM - Security Information and Event Management, is a software-based solution, which combines events and alerts, provides by network agents in real-time mode. It behaves as a “land mine” in front of your system and helps you visualize or pay attention on what is going on and take actions in advance.

A SIEM solution allows events generated by various security applications (such as firewalls, proxies, intrusion prevention systems and antivirus) to be collected, normalized, stored and correlated in order to enable a rapid identification and response to incidents. A standard SIEM tool would include the following topics:

• Combine the features offered in both technologies SIM (Security Information Management) and SEM (Security Event Management). Real-time access, centralized and consistent to all logs and security events, regardless of the technology and manufacturer;

• Correlation of heterogeneous technologies logs, connecting common or significant attributes between sources, in order to transform the data into useful information;

• Identification of behaviours, incidents, fraud, anomalies and baseline breaks;

• Alerts and notifications triggered automatically in the event of non-compliance with security policies, regulatory standards or according to pre-established business rules;

• Sophisticated reporting on environmental safety conditions for SOC (Security Operations Centre) teams auditing and incident response;

• Retention and indexing long-term data allowing subsequent forensic analysis;


• Auditing event log related information.

The concept of a SIEM system can represented as indicated in the picture:

6.9 Public server configuration

…

It is very important to minimize risks by securing such servers. Here are a few good practices:

(a) Architecture: Install the server in a DMZ dedicated zone, for example, a semi-private network that is visible through the network’s firewalls, but that is not part of the private networks of an organization;

(b) Filtering:

(i) Protect the server from network access by a firewall filtering all network fluxes flows, but the port used by the service to access the server;

(ii) …

(c) Bandwidth: A bandwidth management tool should be used to avoid excessive use of bandwidth by a single user (or group of users);

(d) System/application:

(i) The server should process as few types of data as possible (for example, do not combine multiple server applications on the same virtual or physical system);

(ii) The server should be stripped of all unnecessary services and applications, see also section 6.1 for system security;

(iii) …

__________


Annex 5 to draft Recommendation 3.5/1 (CBS-16)

AMEND GUIDE TO VIRTUAL PRIVATE NETWORKS (VPN) VIA THE INTERNET BETWEEN GTS CENTRES (WMO-No. 1116) (AVAILABLE IN ENGLISH ONLY)

Make the following amendments to the Guide to Information Technology Security (WMO-No. 1115) and the Guide to Virtual Private Networks (VPN) via the Internet between GTS centres (WMO-No. 1116)

(See http://wis.wmo.int/file=2481 for authors’ full text track changes)

1. Under 2.2 Types of virtual private networks

(i) Asynchronous Transfer Mode (ATM) and Frame Relay connection;

(ii) Multiprotocol Label Switching;

(iii) Virtual Private LAN Service;

(iv) Link-Layer Encryption (Layer 2 Tunnelling Protocol (L2TP) or Point-to-Point Tunnelling Protocol (PPTP));

2. Under 2.2.1.1 Asynchronous Transfer Mode and Frame Relay

Following the definition of VPN given in chapter 1, early data network, such as ATM and Frame Relay solutions, must be considered as VPNs. By construction, a Frame Relay (and ATM) network, such as the Regional Meteorological Data Communications Network (RMDCN), is a VPN. The provider Orange Business Services (OBS) has a network that is securely divided among all customers. Therefore, on a global telecommunication system, multiple isolated sub-networks coexist. In this case, the VPNs rely on the operator.

3. Under 2.2.1.2 Multiprotocol Label Switching

This solution is now widely offered by operators.

Virtual Private LAN Service

VPLS is a way to provide Ethernet-based multipoint-to-multipoint communication over IP or MPLS networks. It allows geographically dispersed sites to share an Ethernet broadcast domain by connecting sites through pseudo-wires, and VPLS allows any-to-any (multipoint) connectivity.

4. Netscape created the protocol SSL. In the TCP/IP layering model it is on top of the TCP layer. Therefore, it could be used for adding security (strong authentication and encryption) for all TCP-based application (telnet, File Transfer Protocol (FTP), etc.). SSL is no longer recommended for use, all SSL versions are deprecated by now. The recommended protocol is now TLS. Companies use this technology to provide secure remote access to their internal infrastructure by using SSL/TLS VPNs with additional strong authentication, Under 2.2.2.1 Secure Socket Layer and Transport Layer Security

4. Under 3.1 Internet Protocol Security architecture

From RFC 2401 (now replaced by RFC 4301; Kent and Seo, 2005；RFC 4301 partly replaced by RFC 6040, Briscoe, 2010 and RFC 7619, Smyslov and Wouters, 2015):

http://wis.wmo.int/iwm


5. Under 4.2.1 Physical layers

– Frame Relay lines: The leased line is replaced by a connection to a Frame Relay network, but only two peers share the same Frame Relay network

– An MPLS network such as the RMDCN （ as WIS core network ） in Region VI is such a network

– Connections using the Internet

– Satellite communication channels

…

With the growth of products and data, and with the upcoming Weather WMO Information System (WIS) network, National Centres (NCs), Data Collection or Production Centres (DCPCs) and Global Information System Centres (GISCs) will want to exchange much more information. …

__________


INFORMACIÓN GENERAL PARA SUSTENTAR LA DECISIÓN/RECOMENDACIÓN

NO SE INCLUYE EN EL INFORME DE LA REUNIÓN

Referencias:

1. Control de la Vigilancia Meteorológica Mundial - http://www.wmo.int/pages/prog/www/WDM/wdm_monitoring.html

2. Manual del Sistema Mundial de Telecomunicación (OMM-Nº 386) – http://wis.wmo.int/GTS-manual

3. Guide to IT Security (Guía sobre seguridad de la tecnología de la información) (WMO-No. 1115) - http://wis.wmo.int/GTS-security

4. Guide to VPN (Guía sobre redes privadas virtuales por Internet entre centros del Sistema Mundial de Telecomunicación) (WMO-No. 1116) – http://wis.wmo.int/gts-vpn

5. Comisión de Sistemas Básicos - Reunión extraordinaria: Informe final abreviado con resoluciones y recomendaciones (2014) (OMM-Nº 1140) - http://library.wmo.int/opac/index.php?lvl=notice_display&id=17227#.WASM3CT9l1A

6. Decimoséptimo Congreso Meteorológico Mundial - Informe final abreviado con resoluciones (OMM-Nº 1157) - http://library.wmo.int/opac/index.php?lvl=notice_display&id=18692#.WASNNyT9l1A

7. Reuniones sobre el Sistema mundial integrado de sistemas de observación de la OMM - Informes finales - http://www.wmo.int/pages/prog/www/WIGOS-WIS/reports.html

1. Introducción

El Manual del Sistema Mundial de Telecomunicación (OMM-Nº 386), y sus guías correspondientes, proporciona información sobre el funcionamiento, el control y la seguridad del Sistema Mundial de Telecomunicación. Contiene asimismo información sobre las prácticas relativas al control integrado del funcionamiento de la Vigilancia Meteorológica Mundial (VMM).

2. Guía sobre la ejecución del control integrado del funcionamiento de la Vigilancia Meteorológica Mundial

2.1. Históricamente, los centros regionales de telecomunicaciones (CRT) vinculados al Sistema Mundial de Telecomunicación (SMT) han sido un emplazamiento eficaz para controlar las observaciones disponibles procedentes del Sistema Mundial de Observación (SMO). La falta de observaciones por parte de los centros regionales de telecomunicaciones indicaba que las observaciones no se habían realizado o no se habían intercambiado satisfactoriamente en el marco del SMT. Por consiguiente, el control integrado del funcionamiento de la VMM tenía dos propósitos: comprobar el encaminamiento del tráfico y la conmutación entre los centros del SMT y controlar el SMO, aspecto más visible para los Miembros. Se aplicaron correcciones operacionales a los problemas encontrados. Las estadísticas relativas a la recepción de datos de observación se publicaban en el sitio web y se presentaban en las reuniones de los órganos integrantes.

2.2. El método de recogida y análisis de los datos también ha evolucionado a lo largo de los años, en particular el desarrollo del sistema de control integrado del funcionamiento de la VMM. Sin embargo, los modelos de análisis y de predicción numérica del tiempo a nivel

http://www.wmo.int/pages/prog/www/WIGOS-WIS/reports.html

http://wis.wmo.int/GTS-security?lvl=notice_display&id=18692#.WASNNyT9l1A

http://wis.wmo.int/GTS-security?lvl=notice_display&id=18692#.WASNNyT9l1A

http://library.wmo.int/opac/index.php?lvl=notice_display&id=17227#.WASM3CT9l1A

http://library.wmo.int/opac/index.php?lvl=notice_display&id=17227#.WASM3CT9l1A

http://library.wmo.int/opac/index.php

http://www.wmo.int/pages/prog/www/WDM/wdm_monitoring.html

http://www.wmo.int/pages/prog/www/ois/rbsn-rbcn/rbsn-rbcn-home.htm

http://www.wmo.int/pages/prog/www/TEM/GTS/index_en.html


mundial también han desarrollado, mediante sus procesos de asimilación, mecanismos de control y de presentación de informes que facilitan información sobre las observaciones, que no solo incluye la recepción, sino también información sobre la calidad de las observaciones y la tendencia de las desviaciones.

2.3 Desde el punto de vista del WIGOS, en lo referente al Sistema Mundial de Información y a otros sistemas de información colaboradores, los CRT no están necesariamente implicados en la transferencia de información entre los sistemas de observación y los usuarios finales. Por consiguiente, el WIGOS está poniendo en marcha actualmente un sistema de control basado en los procesos de asimilación de los centros mundiales de predicción numérica del tiempo. No obstante, el control integrado del funcionamiento de la VMM cuenta con un largo historial de datos disponibles y, por lo tanto, se recomienda continuar con dicho control para mantener la continuidad entre los registros históricos y los registros futuros del nuevo control del WIGOS.

2.4 Se solicitará a la Comisión de Sistemas Básicos que examine el adjunto I-5 del Manual del Sistema Mundial de Telecomunicación, en el que se define el control integrado del funcionamiento de la VMM y la guía asociada, con el fin de incluir los indicativos de estación del WIGOS y las estadísticas de las observaciones producidas cada hora, y seguir realizando el control integrado del funcionamiento de la VMM cuatro veces al año.

3. Actualizaciones del volumen 1 del Manual del Sistema Mundial de Telecomunicación

3.1 En el Manual del Sistema Mundial de Telecomunicación se enumeran los centros que operan como centros regionales de telecomunicaciones y sus áreas de responsabilidad. Los CRT que forman parte de la Red Principal de Telecomunicaciones (RPT) se describen en los adjuntos I-2 y I-3 de la parte I, volumen 1. Los CRT que no forman parte de la RPT se enumeran en el volumen 2. Así pues, habida cuenta de la Resolución 32 (Cg-17) de suspender el volumen 2 del Manual del Sistema Mundial de Telecomunicación, se solicitará a la CSB que considere la posibilidad de actualizar los adjuntos I-2 y I-3 para incluir los centros regionales de telecomunicaciones que no forman parte de la RPT.

3.2 Además de contar con los CRT y sus áreas de responsabilidad, se solicitará a la CSB que examine la futura estructura de encaminamiento del Sistema Mundial de Telecomunicación, teniendo en cuenta el papel de interconexión de todos los CMSI que desempeña la red básica del SIO, y que es necesario para cumplir los requerimientos de intercambio de la red relativos a los riesgos del Sistema de Información de la OMM.

4. Actualización de las directrices del Sistema Mundial de Telecomunicación sobre la seguridad de la tecnología de la información, la red privada virtual y los protocolos TCP/IP

4.1 La seguridad y fiabilidad de los sistemas de información de la OMM se basan en la garantía del mantenimiento adecuado de los sistemas y en la actualización de las directrices relativas a las prácticas y los procedimientos operativos. Se solicitará a la CSB que examine las actualizaciones relevantes de las guías del Manual del Sistema Mundial de Telecomunicación, incluido el adjunto II-15 sobre el uso de los protocolos TCP/IP en el SMT, así como las publicaciones de la OMM Nº 1115 y Nº 1116 relativas a la seguridad de la tecnología de la información y al uso de las redes privadas virtuales en el SMT.

______________

wmo document templatemeetings.wmo.int/cbs-16/spanish/1. versiones para... · web viewthe report...

Documents