The LoTW System
My recent visit to the ARRL HQ was the opportunity to learn much about the new
LOTW initiative (Logbooks of the World). The following article is my understanding of the implementation, and by no means is intended to represnet commitment of the LOTW design team. For more design details please go to Ref.2.
Problem Statement
The first one is cost intensive for the applicant (typically $3 US per
DXCC credit). The second one slows down the award
processing (typically 6-8 wks waiting time).
System Components
The client application will have other important tasks. The new LOTW user must go through authentication process, to get the el.signature.
Once the signature is obtained, each and every log
record to be sent (e.g. QSO) must be electronically signed.
Authentication is typically done per machine installtion, so
that in case of crash, new authentication procedure must
be done, unless appropriate backup is made before.
The el.signed records will be sent to the server, where the system stores them into AUTHENTICATED records DB (Data Base). All
previouly stored records are traversed for each newly submitted
record, looking for a match. If the match is found
(15 minutes criterion) the record is moved into the data base of MATCHED
records for BOTH participants.
The third data base (Award credits) will be populated from
MATCHED records. Credit records will be there even when nobody
asks for them. Other (non-ARRL) Award Managers expressed
interest in having their Award credits hosted on the
same data base of matched records. They may need data base
extensions that are usually not required for the ARRL Award program.
It has been recognized that the question of intellectual
property should be understood, and certain agreement reached
before the logs are submitted.
DX Station/Expedition logs are the opposite of the first, in
that they are the most wanted, but may not submit logs too
often. For the DX stations there may be the underdeveloped
telecommunications infrastructure problem. For the
DXpeditions, log submission into the LOTW system may result
in loss of sponsorship.
In some countries it is habitual to use
'special' prefixes/callsigns on almost any occasion. Those
stations still can submit their logs, but need to have
certificate for each special prefix.
Field checkers will also need the LOTW client application,
and obtain the certificate for each callsign they process.
Now they have to enter authenticated log entries for each
credit their client needs to submit. Special case here is
that some credits need to be entered even when no MATCH is found, since credits are entered from the QSL card.
There are several cases of reused callsign that must be handled:
In all cases each individual will have his own certificate
for the callsign being used. Practically log records will
have different signatures, but award credits will be
accumulated for a single call sign. Where the callsign is
re-issued by the licensing authority, the time
span for award credits accumulation is needed, if the callsign
is re-issued to different individual/organization.
QSL managers would be regular users of LOTW, except they
submiit their client's log records, rather than their own log
records, which carry the manager's signature. The LOTW client
application is somewhat 'specific' so that the same machine
installation can handle more than one authentication certificate.
This feature should be
a standard LOTW client feature, since
new multiple certificates can be added at any time, similar
to multi prefixes case mentioned before.
Non-LOTW el.QSLing systems can get the
appropriate authentication certificates, and can submit
the entire content of their DBs into LOTW. In this case they
act as a QSL manager.
Log records of SK members entered into the data base of
Authenticated records during their life time, will stay there
forever, and can be matched any time.
Once the authentication certificate is not renewed, new
QSO records cannot be entered.
Log records once entered are never
deleted. If a correction is required, a new record
is submitted. There will than be two records in the data base-
one wrong that will never be matched, and the corrected one.
In this sense LOTW does not have the 'closed log' problem.
Some sort of label that the record has been retrieved from
LOTW should be automatically printed as part of the record.
The LOTW users can use LOTW's electronic rendition of the QSL
card, or
create their own rendition (still with record source label).
The original log owner of the QSO record does not have any controll over
the rendition of the QSL card. In that sense, the electronic QSL
cards are similar to books, in that the author does not have any
controll over the book edition (hard cover, illustrations,
or paperback etc.).
It has also be recognized that a large number of users will
have no personal computer at all. They now need some
sort of a 'certified' agent that can print cards for them.
Most likely the agents will not be allowed to
render QSL cards from Authenticated log records. Instead, they
need to obtain the certificate for their client,
enter their log entries (from log copies), have them matched,
and only than printed. Award credits will automatically be
created. Most likely the agents will be compensated by the end user for
this type of service.
Rendering QSL card from the Authenticated, rather than
from the data base of Matched
records would just create more problems.
Following are the cases:
Since the new matching records can happen any time, the
user may ask for frequent printing of QSL cards
for newly matched records.
LOTW does not take responsibility for 'not-in-log'
notification. This should be resolved with the log owner.
In return, LOTW may offer the list of currently stored
authenticated logs, and e-mail contacts.
Miscellaneous
Non-computerized and non-networked users, will need assistance of their agents
to find the list of already credited LOTW records.
Some organizations have expressed interest in using
the LOTW matched records. There are two cases:
MMI to licensing data is available for FCC licensees only.
Other Licensing data bases do not have specified MMI at this time.
Scalability may become the issue if the number of users
becomes too high. It is not seen as an immediate
problem, but may show up in the future. Equally so, more than
one cetrificate managing authority is not considered at this time.
Help Desk support is considered for LOTW users but may
need to scale up for large number of users. Not all
LOTW users will speak English and may need special
condieration for large and extensive user base.
Nenad VE3EXY ....
References:
Future of El.QSL Service
LOTW Design Document
LoTW Record Structure
LoTW Development Status 13.March 2001