| Oracle® Communications EAGLE Database Administration - GTT User's Guide Release 46.8 F11880-02 |
|
 Previous |
 Next |
| Oracle® Communications EAGLE Database Administration - GTT User's Guide Release 46.8 F11880-02 |
|
|
Previous |
Next |
TCAP Opcode Based Routing allows the EAGLE to route messages based on their operation codes. When the TCAP Opcode Based Routing feature is enabled and turned on, this information contained in the TCAP portion of messages is used for performing global title translation. TOBR is also able to process Segmented XUDT(S) message.
TCAP Opcode Based Routing requires that the Flexible Linkset Optional Based Routing feature is enabled and turned on. TCAP Opcode Based Routing can be used with or without the Origin-Based SCCP Routing feature. Table 2-7 shows the type of GTT sets that can be provisioned for GTT selectors based on the features that are enabled and turned on.
TCAP Decoding
As part of the TCAP Opcode Based Routing feature, the EAGLE attempts to decode TCAP portion of all UDT/UDTS/XUDT/XUDTS queries coming to service modules for global title translation. Messages are decoded only if a TOBR Opcode Quantity is enabled. The objective of this decoder is not to validate the correctness of the message but simply to obtain the required TCAP data. The message is validated only for the encoding rules that are required to successfully decode the required TCAP information. In general, Tag-Length-Value encoding is validated; unsupported Tag values are skipped if they are encountered, unless a specific Tag order is expected. If the decoding fails, global title translation is still performed on the message using some default values for the TCAP data that denote their absence in the message. The TCAP Opcode Based Routing feature supports the following messages.
Other message/package types are treated as an unknown message type and are not proceed with the decoding. This is not considered an error, because many non-TCAP SCCP messages are processed by the EAGLE. For these messages, the TCAP data is not used for routing. If an opcode translation set is encountered while performing global title translation, the opcode translation set is considered as a “translation not found” in that set. Such messages are routed based on last matched translation depending on its fallback option. Refer to Flexible Linkset Optional Based Routing for more details on the fallback option.
The application context name (ACN) is used for all supported ITU TCAP messages except Abort messages. No attempt to retrieve the ACN is made for Abort messages. All other supported messages may have a Dialog portion containing Dialogue Request / Unidirectional Dialogue / Dialogue Response PDU, from which the ACN is retrieved. If no Dialog portion is detected, then the ACN is assumed to be NONE. The TCAP Opcode Based Routing feature attempts to find the operation code (opcode) in all supported ITU TCAP messages except Abort. These messages must contain Invoke or Return Result (Last or Not Last) as the first component. If not, the opcode is assumed to be NONE.
At any point of time during the decoding process, if it is found that the current position in TCAP message is extending beyond the SCCP data portion length, the decoder process stops.
TCAP Opcode Based Routing GTT Sets
The TCAP Opcode Based Routing feature introduces the GTT
Set Opcode with set type
opcode. The opcode GTT set supports
translations for ANSI and ITU opcodes.
TOBR Opcode Quantities
enable-ctrl-feat command. These are the
quantities that can be enabled:
MAP Based Routing
These GTT settypes allow additional MAP Components to be used in the selection process. These GTT settypes are allowed to be provisioned ONLY in GTA entries from an OPCODE GTT Set type or one of the other GTT settypes supported by SS7 Firewall feature.
Additional opcodes supported by MAP Based Routing include:
When an MSU is processed by the TOBR GTT translation with the OPTSN as one of MAP Based Routing settypes, the EAGLE decodes the TCAP part and extracts the required TCAP parameter from the MSU. The digits in this parameter are used as the key to search for the translation in the GTT set.
Only TCAP Package Types BEGIN, CONTINUE & END are supported for MAP Based Routing. OPTSN with one of the MAP Based Routing GTT settypes are allowed to be provisioned only for TOBR GTA entries that have PKGTYPE as BGN, or CNT or END.
ent/chg-gttset commands, a new
parameter NPSN (Not Present Set Name) is used to allow provisioning of this
alternate GTT Set.
Note:
The alternate GTT Set will only be used if the MAP parameter is optional and not present in the MSU. If the MAP parameter is mandatory for that opcode or was present but the lookup failed, the NPSN GTT Set will not be used.For some MAP operations, it is possible for IMSI/MSISDN to be present in the Destination Reference of the dialogue portion; however, currently this feature only supports decoding the key from only the component portion of the TCAP part. If the required parameter is not present in the component portion, the parameter will be deemed 'not present' even though it is in the dialogue portion.
If the Dialogue Portion is present but the ACN could not
be decoded, then the default version will be picked up from the
defmapvr parameter for further
processing.
defmapvr is configured in opcode
translation and used for opcodes that have MAP translations associated with it.
Figure 2-11 MAP Based Routing Flowchart
GTT Translations
TCAP Opcode Based Routing Feature Translations with an ANSI Opcode
The key for ANSI opcode translations is the ANSI opcode specifier, the ANSI TCAP Package Type, and the Family (part of ANSI TCAP opcode field). The ANSI opcode specifier values can be 0 to 255, None, and * (any opcode specifier value). The value none indicates the absence of the opcode in the incoming MSU. The ANSI TCAP Package Type values are Unidirectional, Query with Permission, Query without Permission, Response, Conversation with Permission, Conversation without Permission, Abort, and Any. The Family value can be 0 to 255, None, and * (any family value). While provisioning, when ANSI TCAP Package type is specified as Abort, then the ANSI opcode specifier and Family values must be none. Since the opcode specifier and family values exist together in the incoming MSU, both values in the translation must be none if either value is specified as none.
Search Order for the TCAP Opcode Based Routing Feature Translations with an ANSI Opcode
Table 2-15 shows the searching order for The TCAP Opcode Based Routing feature translations with an ANSI opcode. The ANSI opcode translations are matched to ANSI MSUs:
Table 2-15 Search Order for the TCAP Opcode Based Routing Feature Translations with an ANSI Opcode
| Priority | TCAP Package Type | ANSI Opcode | Family |
|---|---|---|---|
| 1 | Exact (package type value) | Exact (the value none or a number) | Exact (the value none or a number) |
| 2 | Exact | Exact | Any |
| 3 | Exact | Any | Exact |
| 4 | Exact | Any | Any |
| 5 | Any | Exact | Exact |
| 6 | Any | Exact | Any |
| 7 | Any | Any | Exact |
| 8 | Any | Any | Any |
TCAP Opcode Based Routing Feature Translations with an ITU Opcode
The key for ITU opcode translations is the ITU opcode, the ITU TCAP Package Type, and the application context name (ACN). The ITU opcode values can be 0 to 255, None, and * (any opcode value). The value none indicates the absence of the opcode in the incoming MSU. The ITU TCAP Package Type values are Begin, End, Continue, Abort, Unidirectional, and Any. The ACN value can be 1 to 7 bytes - the value of each byte is from 0 to 255, none and Any. The none value indicates the absence of the ACN value in the incoming MSU. Though the VGTT feature is not supported for opcode GTT set, different digit length ACNs for the opcode GTT set can be provisioned. While provisioning, when ITU TCAP Package type is specified as Abort, then the ITU opcode and ACN values must be none. An ACN value cannot contain a mixture numbers, the value none, or the value Any. Table 2-16 shows the valid and invalid values for the ACN.
Table 2-16 Valid and Invalid ACN Values
| ACN Value | Does The TCAP Opcode Based Routing Feature Support this ACN? | Information |
|---|---|---|
| Bytes 1-2-3-4-5 | Yes | The remaining bytes are treated as None. |
| Bytes 1-2-3-4-5-6-7 | Yes | |
| Byte 1 | Yes | The remaining bytes are treated as None. |
| None | Yes | All the bytes are treated as None. |
| Any | Yes | All the bytes are treated as Any. |
| Byte 1-none-Byte 2 | No | |
| Byte 1-any-Byte 3-Byte4 | No | |
| Any-Byte1 | No | |
| None-Any-Byte1 | No |
Search Order for the TCAP Opcode Based Routing Feature Translations with an ITU Opcode
Table 2-17 shows the search order for the TCAP Opcode Based Routing feature translations with an ITU opcode when the TCAP Opcode Based Routing feature is enabled and turned on. The ITU opcode translations are only matched to ITU MSUs. If any MSU contains a 7-byte ACN value, an attempt is made to match the 7-byte ACN values with the values in the database. If a match is not found, no attempt is made to match any 6-/5-/4-/3-/2-/1-byte ACN values in the database. An attempt is made to match to any ACN=ANY entries in the database, if these entries are provisioned in the database.
Table 2-17 Search Order for the TCAP Opcode Based Routing Feature Translations with an ITU Opcode
| Priority | TCAP Package Type | ANSI Opcode | ACN |
|---|---|---|---|
| 1 | Exact (package type value) | Exact (the value none or a number) | Exact (the value none or a number) |
| 2 | Exact | Exact | Any |
| 3 | Exact | Any | Exact |
| 4 | Exact | Any | Any |
| 5 | Any | Exact | Exact |
| 6 | Any | Exact | Any |
| 7 | Any | Any | Exact |
| 8 | Any | Any | Any |
TCAP Segmentation SMS Support Phase 2
An objective of the TCAP Opcode Based Routing feature is to allow EAGLE to route segmented TCAP SMS messages in the same manner as non-segmented TCAP messages are routed. This would mean routing all TCAP SMS messages within a particular transaction to the same place. Routing rules based on the opcode are used to route messages for special application handling. These rules work well for non-segmented TCAP messages. However they do not work well for segmented TCAP messages, because the initial BEGIN message does not contain an opcode. These messages must be identified for special routing based on other criteria. The TCAP Opcode Based Routing feature achieves this discrimination by allowing the EAGLE to route messages based on the TCAP Opcode and Dialogue portion information in the message. The EAGLE uses the Application Context Name from the Dialogue portion to route the TCAP Begin messages without the component portion (and without the operation code). The same routing rules to route messages with an ACN and opcode, an ACN only, or an opcode only value can be used. GSM SMS messages work particularly well in this solution, because there is a 1 to 1 correspondence between the ACN and opcode values.
Hardware Requirements
To enable the TCAP Opcode Based Routing feature E5-SM4G cards must be provisioned in the database. Any SMs must be replaced by the E5-SM4G cards.
Provisioning the TCAP Opcode Based Routing Feature
To provision the TCAP Opcode Based Routing feature, perform these steps.
chg-feat command. Add the required
E5-SM4G cards to the database using the
ent-card command. Perform the
Adding a Service Module
procedure.
enable-ctrl-feat and the
chg-ctrl-feat commands. Perform the
Activating the TCAP Opcode Based Routing Feature
procedure. To enable and turn on the TCAP Opcode Based Routing feature, the
Flexible Linkset Optional Based Routing feature must be enabled and turned on.
The status of the Flexible Linkset Optional Based Routing feature is verified
when the
Activating the TCAP Opcode Based Routing Feature
procedure is performed.
enable-ctrl-feat command. Perform
the
Enabling a TOBR Opcode Quantity
procedure.
ent-gttset command. Perform the
Adding a GTT Set
procedure.
ent-gta command. Perform the
Adding Global Title Address Information
procedure.
ent-gttsel command. Perform the
Adding a GTT Selector
procedure.
