www.tspforum.com

Written by DB

Time Sync - The Network Time Synchronization feature is designed to ensure that all time stamps in a network are synchronized from one source. One switch becomes the master for this purpose. In a private network environment, each switch in the network has an individual system clock. These system clocks can, under certain conditions, lose or gain time, causing inaccurate time stamps for different features. Also, in a private network, several switches can be located in different time zones. As features become more centralized in a network environment, it is useful to have time stamps based on one time zone.

To provide Time Synchronization on a network-wide basis, Meridian Customer Defined Integrated Services Digital Network (ISDN) nodes can request Time Synchronization from another node, using D-channel messages. Therefore, Slave switches can request the time from the Master switch, while the Master switch can do the same to a Backup node. A time difference (or delta) is provided for every node, in order to distinguish time zones for time usage by local features (e.g., Automatic Wake-up) and centralized ones (e.g., Centralized Call Detail Recording).

The Time Synchronization request messages are composed of:
• the message identifier
• the requester's ID
• the time
• the date
• the time-adjust factor

IDs are virtual DNs, and are used to route the messages. On the Slaves, Time Synchronization requests are sent automatically under the background routines (default setup) or with the daily routines (optional setup), every time a time change is performed (to accurately set the seconds), and on every SYSLOAD and initialization. On the Master, Time Synchronization requests are sent to a Backup node upon initialization and, therefore, after SYSLOAD. The Master will be forbidden to synchronize Slave switches during these backup periods. In the rare event where Master and Backup nodes would start requesting synchronization at the same time, the real time will be considered to be on the Slave node, if it is not initializing. If both nodes are only initializing, the real time would be considered to be carried by the Master switch. If a SYSLOAD occurs at the Master and the Slave is initializing, the real time would be considered to be carried by the Slave switch. A warning message will be printed if both switches SYSLOAD, and all Time Synchronization would be put to a halt until the Master’s clock is reset.

If no answer is received on the first time synchronization request (by the end of the request time-out), extra Time Synchronization requests will be sent. If there is still no answer on the third time synchronization request, a warning message will be issued.

Note 1: Upon SYSLOAD, the clock starts on time zero, while upon initialization, only the seconds are lost.

Note 2: Through service change (LD 2) or through an Attendant Console, the clock can be reset to the correct time if desired. If the Network Time Synchronization feature is on, then the Master will be requested for synchronization upon these service changes (to permit fine synchronization).
Operating parameters
This feature uses D-channel messaging over a Meridian Customer Defined Integrated Services Digital Network (ISDN). Feature interactions
Time-of-day Adjustment
Every time LD 2 is used to change the system time, a request for synchronization will be made of the Master to accurately set the seconds.
Time and Date (TAD) Attendant key
As done with LD 2, every time the TAD key is used to change the system time, a request for synchronization will be made to the Master to accurately set the seconds.
Call Detail Recording (CDR)
Upon receipt of synchronization messages, Slave switches will issue CDR records (if so equipped) for monitoring the feature. These CDR records will be identical to those issued by a time change performed in LD 2 or by an attendant’s TAD key.

Feature packaging
This feature is included with the Integrated Services Digital Network Supplementary Features (ISDNS) package 161.
Feature implementation
The following parameters are used to configure Network Time Synchronization:
• Node Status: Can either be Master, Slave, or standard stand-alone node (MAST, SLAV or STDA).
• Customer Number: Customer that will issue and receive the Network Time Synchronization messages. The default value is “0”. For a change (only possible on switches with the multi-customer package) to be accepted, the customer should already exist. Furthermore, the Local DN has to be reentered.
• Local DN: Virtual DN (access code included) dedicated for synchronization services on the Local node; up to 16 digits. A call with these routing digits should terminate on the previously designated customer.
• Master or Backup DN: Virtual DN (access code included) dedicated for synchronization services on the Master or Backup node; up to 16 digits.
• Time Delta: Time difference added to the local time in order to get the Master or Backup time. The entry is prefixed with the digit 1 for positive and 0 for negative.
• Requesting mode: Operating mode used to request the time synchronization messages (i.e., with the background routines (default setup) or with the daily services (BKGD or DSVC)).
Note: The Node Status, Customer Number, Local DN, and Master or Backup DN parameters must be configured for the Network Time Synchronization feature to be operational.

Task summary list
The following is a summary of the tasks in this section:
1 LD 2 – Define entries for the Network Time Synchronization feature.
2 LD 22 – Print the DN type for the Network Time Synchronization Virtual DN. The DN type is “TIME”.
LD 2 – Define entries for the Network Time Synchronization feature.
The following commands are Network Time Synchronization feature specific:
Query Node Status (Type Time Synchronization Status).
The command format is:
INPUTOUTPUT
.TTSS.TTSS (STATUS)
Example:
.TTSS.TTSS MAST
Set Node Status (Set Time Synchronization Status).
The command format is:
.STSS (status)
where status can be:
STDA — stand-alone (default)
MAST — Master
SLAV — Slave
Example:
.STSS SLAV

Query Customer in charge (Type Time Synchronization Customer).
The command format is:
INPUTOUTPUT
.TTSC.TTSC (CUSTOMER NUMBER)
Example:
.TTSC.TTSC 5
Set Customer in charge (Set Time Synchronization Customer).
The command format is:
.STSC (customer number)
where customer can be:
0 - 99 — 0 is default.
Example:
.STSC 5
Query Local Virtual DN (Type Local DN).
The command format is:
INPUTOUTPUT
.TLDN.TLDN (DN)
Example (for 6 = ESN access code, 613 = ESN location code, 5999 = DN):
.TLDN.TLDN 66135999
.SLDN (dn)
Example:
.SLDN 66135999 DN).

INPUTOUTPUT

Set Local Virtual DN (Set Local DN).
The command format is:
Query Master or Backup Time Synchronization Number (Type Master
The command format is:
.TMDN.TMDN (DN) Example (for 6 = Outside line, 514 = ESN code, 3999 = DN):
.TMDN.TMDN 65143999
Set Master or Backup Time Synchronization Number (Set Master DN).
The command format is:
.SMDN (dn)
Example:
.SMDN 65143999

Query Time Delta.
The command format is:
INPUT OUTPUT
.TDEL.TDEL (SIGN) (HR) (MIN)
Example:
.TDEL.TDEL 0 01 30
Set Time Delta.
The command format is:
.SDEL (sign) (hr) (min)
where:
sign – is the time-adjust factor direction indicator which can be:
0 — to indicate the Master switch is behind in time.
or
1 — to indicate the Master switch is ahead in time.
hr – is the number of hours the time must be adjusted by and can be any number from 0 to 23, and min – is the number of minutes the time must be adjusted by and can be any number from 0 to 59. 0 is the default for the SDEL parameters.
Example:
.SDEL 1 23 00
Note: The hour and minute entries are two digits. The minute entry is defaulted to zero if not entered. “1” identifies a positive delta (Master is ahead in time), “0” identifies a negative delta.
Example:
Query Requesting Mode (Type MODe).
The command format is:
INPUT OUTPUT
.TMOD.TMOD (MODE)
.TMOD.TMOD BKGD
Set Requesting Mode (Set MODe).
The command format is:
.SMOD (mode)
where mode can be:
BKGD — Background (default)
or
DSVC — Daily Service (midnight)
Example:
.SMOD DSVC

LD 22 – Print the DN type for the Network Time Synchronization Virtual DN. The DN type is “TIME”.
Feature operation
Each node of the network that is to be synchronized sets its status (i.e., Master, Slave, or Standard stand-alone (the feature is not used)). The craftsperson also sets the node's customer in charge of synchronizing the switch (that customer will request Time Synchronization and receive the time from the Master or Backup switch). The customer must already exist, prior to referencing it, and then sets the local access codes with the virtual DN, the Master (or Backup) routing digits, the time difference between local and Master nodes, and the requesting mode (for example, performed under the background routines (default) or the daily services. The time delta and the requesting mode are optional entries). The time synchronization feature is designed to work in a Meridian Customer Defined Integrated Services Digital Network (ISDN) environment, using D-channel messages. The synchronization messages are carried by TCAP facility messages on a Meridian Customer Defined ISDN, and routed according to the configuration defined in LD 2.
Once the configuration is defined in LD 2, the Slaves will automatically start requesting “time-stamps” from the Master periodically, upon initialize, and when the time and date is changed in LD 2. The message to be sent is identified as being a time synchronization request. The stored Master's routing digits (access codes + virtual DN) are used to route the synchronization requests. As part of the request, the requester's access codes + virtual DN is sent to provide the Master with a way back to the requesting node.
Upon receipt at the Master node, the terminating DN is recognized as being a time synchronization virtual DN, and the request is then processed. The processing consists of constructing a message, identified as being a time synchronization response and originating from that virtual DN, which includes:
• time
• date, and
• time-adjust factor (if used).
The message is then routed to the Slave using the access codes and virtual DN provided with the request. The time-adjust factor is sent to all Slaves in order to have the whole network correct any inaccurate clock settings in unison, if any slippage correction is necessary.
Up to three requests will be sent at one minute intervals, to allow the system to overcome possible temporary malfunctions. On receipt of the time message, the requester verifies the originator's ID (its virtual DN), and updates its clock accordingly (i.e., equal to the time sent minus the time delta between the two switches). If equipped with the CDR package, a time change record is provided with every time synchronization occurrence.

I hope that this helps you in setting up your ITG network!. According to this information that I've managed to find, I think that it should work ok. You must have all of your Nodes pointing to one main one!.