MTP3:Link Configuration

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(more clean up)
(more clean-up)
 
Line 4: Line 4:
 
General explanation of the parameters of configuration:
 
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 '''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 '''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 '''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).  
+
 
 +
 
 +
----
 +
 
 +
 
 +
*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).  
  
  
Line 31: Line 36:
  
  
*The 'Maximum frame length' parameter specifies the maximum frame length for a message signal unit
+
----
 +
 
 +
 
 +
*The '''Maximum frame length''' parameter specifies the maximum frame length for a message signal unit
  
  
Line 37: Line 45:
  
  
*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:
+
----
 +
 
 +
 
 +
*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:
  
  
Line 60: Line 71:
  
  
'''NOTE:''' This field does not have significance for TTC and NTT. For international networks or networks without multiple congestion states, MessagePriority should be configured with TB640_SS7_MTP3_MESSAGE_PRIORITY_NOT_USED.
+
'''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.
+
----
 +
 
 +
 
 +
*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.
  
  
Line 69: Line 83:
  
  
*The 'Priority 0, 1, 2 and 3 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.
+
*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.
  
  
Line 75: Line 89:
  
  
*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 '''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.
*The maximum times to retry SLTM. 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.
+
*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.
  
  
Line 82: Line 96:
  
  
*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.
+
*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.
  
  
Line 88: Line 102:
  
  
*The link test character array specifies the character pattern for the SLTM message
+
*The '''Link test character''' array specifies the character pattern for the SLTM message
  
  
Line 94: Line 108:
  
  
*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.
+
*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.
  
  
Line 100: Line 114:
  
  
*The 'Link timer' configuration parameters have the following definitions:
+
----
 +
 
 +
 
 +
*The '''Link timer configuration''' parameters have the following definitions:
  
  
Line 134: Line 151:
  
 
'''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.
 
'''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:
 
The '''non-standard timers''' have the following definitions:
 +
  
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
Line 164: Line 185:
  
  
*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'.
+
----
 +
 
 +
 
 +
*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 (with TB640_MSG_ID_SS7_MTP3_OP_LINK_ALLOC) to a linkset and changed the number active links of the linkset (with B640_MSG_ID_SS7_MTP3_OP_LINKSET_SET_PARAMS). 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 LinkPriority of the remaining links in the linkset do not become discontinuous after deletion of this link.
+
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.

Latest revision as of 16:04, 27 August 2009

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.

Personal tools