World meteorological organization
|
|  Yüklə 0.96 Mb.
|
Preliminary Results of the Survey on GTS transmission and MTDCF (Submitted by ET-OI Co-chair)
ACTION PROPOSED The Implementation Co-ordination Team is invited to review the results of the survey Appendices: A. Questionnaire provided to RTH centres for conducting the survey B. Survey results on length of meteorological messages and size limits of message and file circuits C. Survey results on Migration to Table Driven Code Form D. Summary of comments from the survey questionnaire returns 1. Purpose and background The outcome of the joint meeting of the Coordination Team on Migration to Table Driven Code Forms (CT-MTDCF) and Expert Team on Data Representation and Codes (ET-DRC) held in Geneva, 1-5 September 2008 noted that there are still systems within the GTS that cannot handle messages of 500K octets in the transmission of binary messages. A review of the situation is required for all RTH centres and their associated NMCs as the problem will affect the exchange of data including data in TDCF. The meeting also recommended ET-OI to consider facilitating the step-by-step migration to TDCF by assisting in the arrangements between zones of responsibility of MTN and RTH centres such that the migration of some types of data can be completed in certain zones of responsibility of an RTH or MTN centre with no more requirements for the parallel exchange of data in both Traditional Alphanumeric Code (TAC) and TDCF when data are presented in BUFR1. The purpose of the survey is intended to examine the following:
2. Distribution and collection of questionnaire Focal Points for RTH Dakar, Tokyo, Brazil, Washington, Melbourne and Offenbach representing their regions are requested to distribute and collect completed questionnaires for their RTH centres and NMCs associated with their centre during the period 22 October to 7 November 2008. A copy of the questionnaire is available at Appendix A. Focal Points of RTH Tokyo and Melbourne are responsible to compile all the responses and present the results of the finding to the CBS ISS Implementation-Coordination Team on Information Systems and Services (ICT-ISS) on 10-12 November 2008. A total of 77 RTH and NMCs responded to the questionnaires as of 7 November 2008. It is possible that the survey should be able to collect some more returns but the tight schedule for analysis and preparation of the report for the ICT-ISS does not allow for any further extension of the survey. Nevertheless the record number of returns collected over the limited period of less than 3 weeks already produced a good sample to generate some preliminary results which are indicative of the overall conditions among the centres. 3. Preliminary results While best efforts are made to follow up with the centres to validate the answers and clarify some of their figures returned which are suspicious it is not possible to allow sufficient time to collect feedbacks from the centres and compile the final results. It should be noted that at this stage the results should be taken as preliminary. Final results is expected in mid-December to allow some time to follow up with non-responses particularly centres in Region III and IV. 3.1 Summary of returns Comparing with a similar survey conducted by the CT-MTDCF in December 2007 this one has more than double in total responses and it has more representative samples in RA I and V. However, RA I
III and IV are still less than adequate and do not provide a representative sample of the respective regions. The centres with completed questionnaires returned by 7 Nov 2008 are as follows:
Efforts to follow up with the centres in RA III and IV should be made before the final results of the survey are presented. 3.2 Length of meteorological messages and size limits According to the Manual on the GTS and with effect from 7 November 2007 bulletins of alphanumeric data transmitted on GTS should not exceed 15K and maximum length of bulletins for binary data has increased to 500K. Practical implementation for most RTH and NMCs indicate that the 15K limit for alphanumeric message and file circuits is not strictly followed especially for file transmission with 64% of the centres having removed the size limit in alphanumeric file transmission and 47% of them having alphanumeric message circuits running without the 15K limit. Similarly for binary transmission there are 56% and 43% of centres with their file and message circuits running at limits of >500K.
The most common reason is to avoid losing data and causing problems when circuits are encountering long messages with length more than 15K. When this happens the message switching system would normally raise an alarm or dropping the circuit and potentially causing a loop of connection and disconnection resulting loss of data to the receiving centre. This is not considered to be a huge problem because even though the hard limit of 15 K is not implemented some centres are able to implement a soft limit in the message recognising or decoding process to detect the offending long messages and take appropriate actions with the centre where the long messages are originated. The interesting result to notice is the small number of centres not able to receive binary message or file with 500K limit, 9 and 2 centres respectively for message and file circuits. This is in fact more complicated than the numbers indicated in the result. The 2 Russian Federation centres (Moscow, Khabarovsk) and Kiev can be eliminated because they have FTP WMO binary circuits that can receive data 500K or more. Novosibirsk did not answer the question properly and requires follow up confirmation from the centre. Helsinki is able to generate, decode and process BUFR message but has indicated 15K in both message and file binary circuits. This may not be true. The other group of centres has the real problem. They currently have no requirement to process BUFR messages and are unable to receive binary messages. Baku, Nadi, Honiara, Port Moresby and a number of Pacific Island countries are of this category. There may be some more in RAIII and RA IV. Nadi should be able to improve with their systems planned for upgrade soon.
The question (Q.2) to ask if there are any connected users or centres with smaller size limit than the connecting centre is intended to find out more information about centres in its area of responsibility having smaller size limits which they are aware of. However, a lot of centres appear to have no complete knowledge of the size limits of their connected users. Most centres answering ‘NO’ may be assuming ‘NO’ because there are no expressed problems reported from the connected centres. 15 centres reported ‘YES’ and listed some centres while some others centres not responding to this question or listing any centres. 56 centres reported ‘NO’ 3.4 Centres unable to receive message as files Question 3 asked if centres are able to receive files of meteorological bulletins or perform file switching. 5 centres (Baku, Entebbe, Honiara, Oslo and Port Moresby) answered they don’t receive bulletins as files.
Question 4 -7 are intended to find out how many centres are able to generate, decode and process TDCF in either or both BUFR and CREX.
A majority of centres do not generate and decode CREX messages. This is consistent with the idea of directly migration to BUFR rather than going through an intermediate process. It is more important to be able to decode and process BUFR messages rather than just generate BUFR messages for the purpose of migration while still relying on TAC messages for normal operation. It should be noted that a number of centres do not indicate maritime data (cat 4) in their migration plan. This may be an indication that the ocean data centre is not within the same organisation such as CMC in Canada with the ocean data centre under a different Ministry and department. According to what categories of TAC are listed by the centre in their returns we should be able to find the bulletin headers in WMO Volume C1 and to ensure that these bulletins implemented by the centres are switched properly to all other centres. A few bulletins selected from the questionnaire returns to verify if they are announced in Volume C1 or switched properly on GTS indicate that this is not done as properly as the corresponding TAC code forms. The main reason for this not happening is mostly due to the TAC code forms are still reported reliably and the BUFR messages for many stations are practically non-existent. Some centres are not ingestion the BUFR messages if the corresponding TAC code forms are still in use. This is reflected in some answers to Question 6 asking centres to list the name of the TAC for which they are no longer required. A lot of centres listed data categories in CAT 1 such as SYNOP, TEMP, PILOT, etc. This is not a sensible answer because the TAC would still be required for many stations which do not provide BURF reports as yet. Without a rigorous monitoring of the effectiveness of BUFR in replacing TAC with some confidence of not losing data for which there are no corresponding equivalents in BUFR for the same observations it is unlikely that BUFR can replace TAC completely. As RTH Tokyo indicated SATOB is the only type of data that can be completely replaced by the BUFR Atmospheric Motion Vector (AMV).
Question 8 and 9 are intended to examine how many centres are willing to assist in the step-to-step migration. 24 centres are able to do conversion from BUFR to TAC and 26 centres are able to do TAC to BUFR. It should be noted that BUFR to TAC conversion is against the purpose of migration and is not recommended. It may only be used as the last resort for the NMCs who are unable to receive TDCF in BUFR or unable to decode and process all or certain types of TDCF.
However, only 6 out of the 26 centres are willing to offer conversion support for other centres for BUFR to TAC, and 14 out of the 24 centres are willing to offer conversion support for TAC to BUFR. With only 6 centres willing to do the conversion from BUFR to TAC it is less likely or very difficult to provide support for all centres who are unable to decode and process BUFR. A better strategy is to help these centres to implement software that can decode and process BUFR messages.
If the step-by-step migration to TDCF is to proceed only TAC to BUFR conversion is recommended and with 14 centres willing to do the work it is more hopeful that thsi is achievable. 4. Acknowledgement I would like to acknowledge the RTH Focal Points responsible for conducting the survey and collecting the returns in their regions and provided the assistance in such a short notice. In particular, RTH Focal Pont Tokyo Mr Atsushi Shimazaki should be congratulated for successfully completed analysing the returns in record time. Appendix A – Questionnaire provided to RTH centres for conducting the survey
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||