MTP3:Link Configuration
A MTP3 link is used to connect with a MTP2 link; they are connected in a one-to-one fashion.
General explanation of the parameters of configuration:
- The Unique MTP3 link identifier parameter is used to configure identical MTP3 link in each MTP3 module
- The Linkset handle parameter specifies the handle of linkset to which this link belongs
- The Unique MTP2 link identifier parameter specifies the UID of the MTP2 link to which this link belongs. This field is not reconfigurable.
- The Link priority parameter specifies the priority of the link within a linkset. The highest priority is 0. There must be at least one link in a linkset with priority 0. If there are links with different priorities in a linkset, the priorities of the links must be contiguous. For example, there can be no existing links with priority 0, 1, and 3 in a linkset (priority 2 missing).
At any given time, only the in-service links with the highest priority are used to carry traffic on that linkset based on the 'number of active links' in linkset configuration. For example, if there are five links in a linkset, with two at priority 0, two at priority 1, and one at priority 2 and the value of 'Number of active links' in the linkset configuration is 5, then the two in-service links with priority 0 are used to carry the traffic. If one priority 0 link goes out-of-service (OOS), one of the in-service priority 1 links will be used for traffic. The following values are allowed:
| Link priority | Description |
|---|---|
| Highest | N/A |
| 0 | Priority 0, same as highest |
| 1 | Priority 1 |
| 2 | Priority 2 |
| 3 | Priority 3, same as lowest |
| Lowest | N/A |
- The Maximum frame length parameter specifies the maximum frame length for a message signal unit
NOTE: The maximum frame length MUST be set to 272 bytes.
- The Message priority parameter specifies the priority at which MTP3 management messages are sent in case the network allows priorities to be attached with messages (as in ANSI, for example). If the network does not allow priorities to be attached with messages, this is configured to 0. This field is reconfigurable. The following values are allowed:
| Message priority | Description |
|---|---|
| Not used | Used for TTC and NTT variants |
| Highest | For international networks or networks without multiple congestion states |
| 0 | Priority 0, same as highest |
| 1 | Priority 1 |
| 2 | Priority 2 |
| 3 | Priority 3, same as lowest |
| Lowest | N/A |
NOTE: This field does not have significance for TTC and NTT. For international networks or networks without multiple congestion states, the 'Message Priority' parameter should be configured with the value 'Not used'.
- The c-link flag indicates whether the link is a C link (links between mated STPs are C links). This field is specific to ANSI. Allowable values are 'True' or 'False.
NOTE: This information is relevant to STPs only. In ANSI networks, the SLS should not be rotated for the data transferred between the C links, and hence need to be configured appropriately.
- The Priority X message queue length parameters are used to implement multiple levels of congestion on this link. This specifies four different levels of thresholds and does not represent four different queues for the SAP. When MTP3 starts queuing up messages (for example, due to congestion on a link), the messages are queued up in the link. As the queue length grows, different levels of congestion are reached depending upon the values configured for Priority Message Queue Length. The same value of Priority 1 Message Queue Length to Priority 3 Message Queue Length is acceptable, but will result in only one level of congestion. These values are configured based upon the memory available to queue the messages. These fields are reconfigurable.
NOTE: It is essential for international networks to have same values for Priority 1 Message Queue Length to Priority 3 Message Queue Length.
- Regarding the Discard priority parameter, in national networks supporting multiple levels of congestion, if a message is received by MTP3 with a priority less than the current congestion priority of the link (in case the link is congested), then the message is dropped. If it is required to override this feature, this parameter can be configured so that before MTP3 drops a message because of congestion, it checks the message priority. If the message priority is less than the discard priority, the message is dropped. Allowable values: see the table at the top of this page on link priorities.
- Regarding the Maximum times to retry SLTM parameter, when a link is aligned at MTP3, an SLTM (Signaling Link Test Message) message is periodically sent to the peer MTP3 to determine the state of the link and waits for SLTA (Signaling Link Test Acknowledgment) (MTP3 receives SLTA for the SLTM message it sent after level 2 is aligned for an Out-Of-Service (OOS) link). If SLTA is not received, then it repeats the SLTM message un32MaxSLTMRetry before declaring the link OOS.
NOTE: TTC and NTT do not support Signaling Link Test using SLTM/SLTA. Therefore, this field is not applicable for TTC and NTT.
- Regarding the Link selection code for link test parameter, each link between Trillium's node and an adjacent node is assigned a unique 'LinkTestSLC' value between 0 and 15. There can be a maximum of 16 links between two adjacent point codes. This value must be agreed upon by both the ends for each link. This field is reconfigurable.
NOTE: For TTC and NTT, at a signaling point, three MSB bits represent the SLC, and the LSB represents the plane information (0 = PLANE A and 1 = PLANE B). Also note that since the maximum 'LinkTestSLC' value possible is 15, there can be only 16 links possible in any linkset terminating on a particular DPC.
- The Link test character array specifies the character pattern for the SLTM message
NOTE: TTC and NTT do not support signaling link test using SLTM/SLTA. Therefore, the 'TestCharacter [ ]' field is not configured
- Regarding the Link test message length parameter, when MTP3 gets a 'connection confirm' message from layer 2 (as part of a link activation procedure), it sends an SLTM message to align the link at MTP3. In the SLTM message, it sends a character pattern, and expects the same pattern to come back in an SLTA message from the peer. 'Link test message length' specifies the length of the character pattern.
NOTE: TTC and NTT do not support signaling link test using SLTM/SLTA. Therefore, the field un32TestMsgLen is not configured.
- The Link timer configuration parameters have the following definitions:
| Link priority | Description |
|---|---|
| T1 Timer | Delay to avoid mis-sequencing on changeover. Typical value is 800 milliseconds (0.8 second) |
| T2 Timer | Waiting for changeover ack. Typical value is 1400 milliseconds (1.4 seconds) |
| T3 Timer | Delay to avoid mis-sequencing on changeback. Typical value is 800 milliseconds (0.8 second) |
| T4 Timer | Waiting for changeback ack (first). Typical value is 800 milliseconds (0.8 second) |
| T5 Timer | Waiting for changeback ack (second). Typical value is 800 milliseconds (0.8 second) |
| T7 Timer | Waiting for link connection ack. Typical value is 1500 milliseconds (1.5 seconds) |
| T12 Timer | Waiting for uninhibit ack. Typical value is 1150 milliseconds (1.15 seconds) |
| T13 Timer | Waiting for force uninhibit. Typical value is 1150 milliseconds (1.15 seconds) |
| T14 Timer | Waiting for inhibition ack. Typical value is 2500 milliseconds (2.5 seconds) |
| T17 Timer | Delay to avoid oscillation of initial alignment failure. Typical value is 1150 milliseconds (1.15 seconds) |
| T22 Timer | Local inhibit test timer. Typical value is 30,000 milliseconds (30 seconds) for ANSI and 300,000 milliseconds (5 minutes) for ITU |
| T23 Timer | Remote inhibit test timer. Typical value is 30,000 milliseconds (30 seconds) for ANSI and 300,000 milliseconds (5 minutes) for ITU |
NOTE: TTC and NTT do not support inhibition and Signaling Link Test. Therefore, the timers related to these procedures are not configured. Also, timer T5 and T17 are not configured, as they have been removed from TTC and NTT specifications.
The non-standard timers have the following definitions:
| Non-standard timer | Description |
|---|---|
| BSN Requested Timer | This is a Trillium-specific timer. As part of the changeover procedure on a link, MTP3 sends a status request to layer 2 to return the BSN for that link. The value of this timer depends on the customer implementation. For example, if layer 2 and MTP3 are on separate boards, this value is more than when MTP3 and layer 2 exist together on the same board. Typical value is 5000 milliseconds (5 seconds). |
| SLT Timer | This is the same as timer T1 in Q.707. This is also the same as T10 in JT Q.707 (TTC Japan). Typical value is 4000 milliseconds (4 seconds). |
| Connecting Timer | This is a Trillium-specific timer to take care of loss of connect request or connect confirm. To activate a link, MTP3 sends a connect request to layer 2 and starts the 'Connecting Timer' timer. If layer 2 does not send either a connection confirms or disconnects indication, and 'Connecting Timer' expires, MTP3 repeats the connection request and restarts 'Connecting Timer'. 'Connecting Timer' is used by MTP3 to periodically send the connect request to layer 2, in case layer 2 is not responding. Its typical value is between 120,000 milliseconds (2 minutes) to 600,000 milliseconds (10 minutes). |
| PeriodicSigLinkTstTimer | This is the same as timer T2 in Q.707. Typical value is 30,000 milliseconds (30 seconds).) |
| False Link Congestion Detection Timer | This is the same as timer T31 in ANSI'96. Used for ANSI 88, 92 and 96. Typical value is 10,000 milliseconds (10 seconds) |
| Probation Link Oscillation Timer | This is the same as timer T33 in ANSI'96. Used for ANSI 88, 92 and 96. Typical value is 60,000 milliseconds (1 minute) |
| Suspension Link Oscillation Timer | This is the same as timer T34 in ANSI'96. Used for ANSI 88, 92 and 96. Typical value is 5000 milliseconds (5 seconds) |
| Link Referral Craft Timer | This is the same as timer T19 in ANSI'96. Used for ANSI 88, 92 and 96. Typical value is 480,000 milliseconds (8 minutes) |
| Flow Control Request Timer | This is a proprietary Trillium timer. When layer 2 sends a flow control indication to MTP3 indicating onset of flow control, MTP3 sends a status request to layer 2 periodically at the time-out of the 'Flow Control Request Timer' timer. The recommended value for this timer is 30,000 milliseconds (30 seconds) |
| Bind Confirm Wait Timer | This is a proprietary Trillium timer. When MTP3 sends a bind request to layer 2, it starts this timer to wait for the bind confirm. The recommended value for this timer is from 2000 milliseconds (2 seconds) to 5000 milliseconds (5 seconds). |
- The Flush continue flag parameter specifies whether `Flush Buffer' and 'Continue' requests are required to be sent to layer 2 on processor outage recovery. It is 'False' for ITU88, CHINA, TTC and NTT variants of MTP3. Allowable values are 'True' or 'False'.
You can add a new link to a linkset and change the number active links of the linkset. So, you DON’T need to clear and redo the linkset.
NOTE: If you remove a link from a linkset you must verify if the 'Link priority' of the remaining links in the linkset does not become discontinuous after deletion of this link.