Source/destination-dependent modification with AMO KNMAT

1. When is AMO KNMAT used for modification?
   A source/destination-dependent modification with AMO KNMAT and AMO KNFOR should take place whenever the numbers are implicit and cannot be converted into an explicit format due to their structure or whenever a destination node requires an implicit format. Since the OpenScape 4000 specific numbering plan always contains implicit numbers, all modifications regarding tie line codes must be settled using AMO KNMAT. For the NPI=ISDN and NPI=PRIVATE numbering plans, modification using AMO KNMAT makes sense only in exceptional cases.
2. What is the structure of the node connection matrix?
   The node connection matrix managed using AMO KNMAT is set up separately for each node number level and numbering plan. There are nine (3 levels x 3 numbering plans) KNMAT tables that are independent of each other. The selection of tables to be processed is oriented on the NPI and node number levels listed there for incoming numbers. In the case of outgoing numbers, the numbering plan to be selected depends on the destination number, i.e. on the LCR (AMO LODR), and the levels to be processed depend on the levels of the node numbers. Figure 51 shows the principle structure of the node connection matrices.

   Figure 49. Modification matrices and modification points in a three-level network

   
3. How is the matrix processed?
   In regard to the specific numbering plan, the KNMAT tables are always run through from the highest to lowest level (modification point 3->2->1) and all minus entries (abbreviation of digits) are processed. The tables are then processed from the lowest to the highest level (modification point 1->2->3), whereby all plus entries (supplementing of digits) are processed. Minus entries are deducted only if the correspond with the first part of the numbers. Plus entries, on the other hand, are always supplemented unless the number exceeds the maximum length of 22 digits.
   In the case of multi-level KNMAT modification, it is very important to clarify that the node numbers are assigned to precisely one node only on Level 0 and that Levels 1 and 2 describe larger areas of nodes. A node with a physical node number of 1-2-5 in ZAND is clear within the network only with a three-digit node numbers (e.g. "1" for all nodes in Germany, "2" for all nodes in Munich, and "5" for precisely this node in Munich). In the KNMAT modification of this node for Node 1-2-6, however, the virtual node must always be observed, which means that Germany is modified to Germany (1 to 1) in Level 2, Munich to Munich (2 to 2) in Level 1, and Node 5 to Node 6 in Level 0.
4. Why were the modification conditions introduced?
   To prevent ambiguities in the higher levels, AMO KNMAT has a modification condition parameter (MODCON). With this parameter, the entered modification can be executed only under certain conditions. These conditions can be derived from the desired traffic type. A modification can thus be performed only in case of outgoing terminating traffic (ABG), incoming terminating traffic (ANKE), transit under observance of the numbering plan (TRANSH), transit with a change of the numbering plan (TRANSI), never (NONE), or always (ALL) or in case of a combination of these conditions. If the supplementing of digits on Level 2 can thus take place only if the call comes from the node for which AMO KNMAT has been set up and not in a transit node on Level 2, the modification condition MODCON=OUT should be entered.
   In combination with the subscriber-individual authorization DIDBLK (direct inward dialing blocking), the REPEXT special modification condition effects a complete replacement of the "calling number" by a substitute number. REPEXT and DIDBLK are always set whenever station numbers are not known to the central office so that they are replaced by an attendant console number, for example. In case of REPEXT without DIDBLK, the substitute number is also used, but the lower digits with the calling number are overwritten. An example can be found in the Service Manual the "EURO-ISDN CO Interface" chapter.
5. What are "logical" node numbers?
   In addition to the actual area and node numbers of a level, AMO KNMAT has so-called logical node numbers. They were introduced to simplify administration, i.e. to minimize the number of entries in the matrix. The following logical node numbers exist:
   • OWN: All own node or area numbers.
     After entry, the logical OWN node is directly converted into all really own node numbers (according to AMO KNDEF) and should act only as a simplified aid for the administrator. In connection with the logical entry ##### for NUMEXT/NUMRED, the corresponding node code is extracted from AMO KNDEF under consideration of the skip digits for each virtual node number.
   • ROW: Stands for all nodes/areas in the respective level (including the own node).
     The logical node ROW represents a new line or column in AMO KNMAT. If no entry for the precise source/destination relationship exists in the corresponding level and numbering plan or if the MODCON is incorrect, the real source/destination node is replaced by the logical node ROW and an entry is sought there. In the process, only one node number not equal to the own node number is replaced by ROW. Both node numbers are never replaced by ROW at the same time.
   • CDR as special node for call data recording The logical node number CDR is taken into consideration only as a destination node number (parameter DNNOL) in the numbering plan UNKNOWN (parameter NPI). Here, the special modifications for the call data recording can be entered independently of the source node (MODCON=ALL). How the modification should take place is described in the "Call Data Recording" chapter and not dealt with further here.
6. How is the logical node ROW handled?
   Example for the handling of ROW:
   The connection from Node 100 to Node 200 should be established. No entry exists for ONNO/DNNO = 100/200. The KNMAT table is as follows:

   ----------------------------------------------------------------------
   NODE MATRIX FOR NPI = UNKNOWN, LEVEL = 0, OWN NNO = 100
   ----------------------------------------------------------------------
    ONNO |DNNO |CONN|MODCON| NUMEXT              | NUMRED
    / ONNOL|/ DNNOL |      |                     |                       |
   ------+------+----+------+------------------------+-------------------
     100 |ROW  | A  |ALL     | 99                | - 
   ------+------+----+------+------------------------+-------------------
     ROW |  100 | A  |ALL     | 55               | -
   
   
   

   Result:	"99" is supplemented since there is no entry in 100/200 and the own NNO 100 is not replaced by ROW.
   Remark:	A "0" in one of the lower levels of a node number in AMO (e.g. RICHT) is interpreted as ROW in AMO KNMAT if a clear number is contained in one of the higher levels.

   IMPORTANT:

   A targeted entry with ONNO/DNNO always has priority before ROW!
7. How is the OWN logical node handled in connection with the modification conditions?
   A modification can generally take place in an incoming and outgoing manner. For outgoing terminating traffic (MODCON=OUT), modification only takes place in an "outgoing" manner and in an "incoming" manner for incoming terminating traffic (MODCON=IN). In transit traffic, homogeneous transit (MODCON=TRANSH) and transit interworking (MODCON=TRANSI) must be differentiated. To keep the number in the node as short as possible, ONNO will be modified to DNNOL=OWN when incoming in both cases. In TRANSH, the possibly previously abbreviated number is supplemented by these numbers again and then modified with ONNO/DNNO when outgoing. In TRANSI, the possibly previously abbreviated number is kept and modified with ONNOL=OWN to DNNO when outgoing.
8. How is a substitute number set?
   If the parameter SUPPCPN is set in the LATTR of AMO LDAT (see Section ), a substitute number can be set using AMO KNMAT. The applies in case of MODCON=TRANSI and is read from AMO KNMAT with ONNO/DNNO when outgoing.
9. How can the KNMAT modification be configured for the ISDN and PRIVATE numbering plans as well in case of exceptions?
   If, in special cases, explicit numbers also have to be handled with AMO KNMAT when incoming, a pretreatment of the calling number is performed before the KNMAT modification. Every previously explicit number (e.g. 89 722 4711, NPI=ISDN, TON=NATIONAL) is converted into the respectively highest possible format (TON=INTERNAT) using AMO KNDEF and AMO KNPRE. All codes, the respective exit codes, and the prefixes are added (e.g. 0 00 49 0 0 89 0 722 4711). Now, an abbreviation of the desired code can take place using AMO KNMAT (e.g. in the ROW/OWN entry): -00049). Invalid exit codes and prefixes remaining in the number are removed by the program after modification (e.g. 0 0 89 722 4711).
   In the case of the outgoing modification of numbers from the NPI=ISDN and NPI=PRIVATE numbering plans, the codes entered in AMO KNMAT must always be coordinated with AMO KNFOR.

Rules for KNMAT modification

Format-dependent modification

1. What is format-dependent modification?
   Format-dependent modification offers the opportunity to convert an incoming number (calling number) in any format automatically using the codes in AMO KNDEF to a certain destination format (AMO KNFOR).
   This modification method is configured with AMO KNPRE, AMO KNFOR, and AMO KNDEF. It is possible only for the processing of explicit numbers. Since this is the case by default, however, at least in the NPI=ISDN and NPI=PRIVATE numbering plans, the use of format-dependent modification should always be preferred to source/destination-dependent modification in this case.
2. How is the format-dependent modification configured?
   The modification takes place as follows:
   • The entry of the corresponding code in AMO KNDEF.
   • The setting of the node prefix table using AMO KNPRE. Here, you can set the prefixes belonging to the NPI/TON combination and the exit code. This enables a conversation from explicit to implicit numbers and vice versa.
   • The setting of the node format table using AMO KNFOR. The TON entry in KNFOR decides on the format of the number. Since, in the case of overlapping nodes for a virtual node number, it is no longer clear whether the node in question is the part of the overlapping virtual node on the actual physical node or whether it is the part of the overlapping virtual node on another physical node, two TON parameters are introduced: TONIN and TONOUT:
     TONIN or rather, a KNFOR entry on the own node (DNNO=own node number), determines the display format of the number for all telephones on this node (e.g. displays). If no entry exists here, the number is always converted to the lowest possible format (e.g. only the DID number TON=UNKNOWN). An entry with TON=NATIONAL, for example, has the effect that the calling number is always displayed in the national format (e.g. 0 089 722 4711).
     TONOUT or, rather, a KNFOR entry with any number of destination nodes in the network, determines the number format, i.e. the TON, for precisely these nodes. If no entry exists, the highest possible format (e.g. TON=INTERNAT) is taken as the default.
     If TON=UNKNOWN is entered in KNFOR, the number for the corresponding destination node must be implicit. Here, no format-dependent modification is performed, but rather only the entries in AMO KNMAT are processed.

Rules for format-dependent modification