In this section:

The New Zealand variant is based on ITU with the same point code format. The MTP3 has a corresponding New Zealand variant to support the Signaling Route Test Message (SRTM), Signaling Route Test Acknowledgement (SRTA), Unallocated Signaling Point Number (USN) messages for routeset test procedures. Due to compatibility between New Zealand and ITU, there is no SCCP conversion required other than PC mapping (if necessary).

This section provides you with conversion information between New Zealand (ISUP) and ITU (ISUP).

ITU (ISUP) to New Zealand (ISUP)

The following table provides you with the ITU (ISUP) to New Zealand (ISUP) message conversion details.

For information about segmentation, see Segmentation.

ITU (ISUP) to New Zealand (ISUP) Message Conversion

Click to view table

The following table provides the ITU (ISUP) to New Zealand (ISUP) parameter conversion details.

ITU (ISUP) to New Zealand (ISUP) Parameter Conversion

Click to view table

Segmentation

New Zealand does not support segmentation while ITU does, using the Optional Forward/Backward Call Indicators (OFCI and OBCI) bit C for IAM, ANM, ACM, CON, and CPG messages. If an ITU message from the above list is received with an OFCI/OBCI set to segmentation, the message is kept in a list with a lifespan of 2 seconds until a SGM message is received.

If the timer expires, the message pending is sent out without the OFCI/OBCI. If a SGM message is received, the pending MSU has the SGM parameters included. Prior to encode, all the unsupported parameters will be discarded. If the encode still fails, the User-to-User Information parameter is removed first followed by other optional parameters as per specifications.

 

New Zealand (ISUP) to ITU (ISUP)

The following table provides detailed information about the New Zealand (ISUP) to ITU (ISUP) message conversion.

New Zealand (ISUP) to ITU (ISUP) Message Conversion

Click to view table

The following table provides you with New Zealand (ISUP) to ITU (ISUP) parameter conversion details.

New Zealand (ISUP) to ITU (ISUP) Parameter Conversion

Click to view table

Overload

The Overload (OLM) message and procedure is a national New Zealand implementation. On receipt of an OLM, the end switch should drop the call and return a REL. Unfortunately, most ITU switches consider OLM a national matter and simply discard the OLM.

A new configurable parameter has been added in the Route Mapping (refer to Route Mapping Configuration Screen) to determine if the destination ITU switch supports overload. If the flag is disabled as set be default, the conversion proceeds as follows.

  1. On receipt of an OLM from New Zealand, a REL is returned to the New Zealand side while an RSC is forwarded to the ITU switch.

  2. The RSC triggers the release of the call at the ITU switch.

  3. A lifespan timer of 15 seconds is started while pending with the resulting RLC messages.

  4. The response RLC from the ITU and New Zealand switches is captured and discarded as there responses are not expected at the end switches.

The receipt of an IAM, ACM, ANM, or CON resets any existing OLM records for the given DPC-OPC-CIC.

ITU to New Zealand Call Diversion

According to the New Zealand specification PTC331-C, the Call Diversion has standard and alternate procedures (see the following figure and Figure Call Diversion (Alternate) or Section C-103 and C-104 in the PTC331-C). In ITU, only the standard procedure is supported.

Call Diversion (Standard)

Call Diversion (Alternate)

The CPG messages received prior to an ACM must be kept and sent first out following the ACM. Call state is required to keep track of that call in incoming CPG and ACM from New Zealand side for Call Diversion. An ACM/CON is expected in T7 seconds (20 to 30 seconds) to complete the call. A Call Diversion life span timer of 60 seconds are started.

A non-distributed implementation is feasible based on incoming New Zealand CPG, ACM, ANM/CON/REL/RLC and the lifespan timer. Up to four CPGs can be kept in the alternate Call Diversion implementation. Any CPGs exceeding this maximum are discarded.

On Call Diversion lifespan timer expiry, the CPG lists is cleared (discard pending CPG messages if any).

Note

The only caveat to the implementation is the receipt of an unexpected CPG followed by a new call on that same DPC-OPC-CIC prior to the resulting Call Diversion record lifespan expiry. In this scenario, the CPG is forwarded following the ACM as per the alternate procedure (see the preceding Figure Call Diversion (Alternate)). Unexpected CPG messages are now discarded instead of forwarded along on record lifespan expiry.

 

  • No labels