 title (GT) or a subsystem number (SSN) combined with a point code (PC) In Fig. 5.12, the former is assumed. This solution makes reference points independent of how TCAP users are con- figured in the SCCP network. Furthermore, each reference point can be defined as a protocol of its own, meaning that, e.g. MAP operation must be uniquely identi- fied only within a reference point. The prerequisite for this solution is only that TCAP supports reference point identification in its protocol and provides transla- tion between such identifiers and GTs. A closer look at the TCAP specification reveals, however, that no such parame- ter exists. Different MAP logical nodes are instead addressed by SCCP addresses (see Fig. 5.5), mixed with SCCP addresses that identify other logical nodes that do 5 Protocol Network Modelling not use TCAP and that are not MAP nodes. This approach makes addressing between MAP logical nodes dependent on how the nodes are configured in the SCCP network. Furthermore, each MAP operation must be uniquely identified over all nine reference points, although operations over different MAP reference points have nothing more in common than that they rely on TCAP. As a conse- quence, the MAP protocol must frequently be updated, resulting in frequent prod- uct changes. The MAP protocol specification is very large, and the fact that it is neither structured into reference points nor protocol networks makes it an instru- ment for specialists only. The reason that protocols like MAP, BSSAP and BTSM have become defined as multiple reference point protocols is that the designers have tried to avoid extend- ing, e.g. TCAP with configuration mechanisms, such as translating RPid to GT. Instead, they have produced single protocol specifications for each type of trans- port mechanism. This is understandable, considering that the properties of the transport service affect the design of the protocol. The transport mechanism for MAP is remote operation calls, provided by TCAP using connection-less SCCP. The transport m