SS7 SCCP and TCAP support the non-connection-oriented messaging transactions required by IN. The operation of SCCP and TCAP were outlined in Chapter 3 and we now illustrate the message coding details for a typical IN transaction. In fact the particular message flow illustrated here is for a mobile call involving a CAP (CAMEL application protocol) request. As we discussed earlier, there is strong equivalence between the CAP and the INAP protocols. There are some application parameter differences, but the behaviour of SCCP and TCAP in support of the messaging is identical in both cases and so the illustration here would be similar for an INAP transaction scenario.

We show the messaging required for a call where the IN service logic requests the SSF (the gsmSSF in this case) for end of call notification. This might be used, for instance, where the SCF needs to log the call s duration, perhaps in order to decrement the customer s prepaid account by the cost of the call.

Figure A3.1 shows the seven messages in the example sequence, and transcripts of the individual messages themselves are shown on the following pages.

The first event shown is the receipt by the gsmSCF of the CAP I_DP in a TCAP Begin message. The accompanying parameters transferred are:

• service key

• called party number

• calling party number

• calling party s category

• IP SSP capabilities

• bearer capability

• event type BCSM

• IMSI (international mobile subscriber identity)

• Call reference number

• MSC address.

Figure A3.1: TCAP messages illustrated

The first seven parameters are taken...