You are here

Pre-arranged End

5 posts / 0 new
Last post
Pre-arranged End


May i know under what circumstances, an SSP sends the pre-arranged end. Prior to this, SCP sends a RRBCSM event to monitor O_disconnect or O_Abandon DPs by a TC_continue messge in response to the IDP sent by SSP.

A party's calling category was a Pay-phone.

Re:In order to close the transaction

I think Pre-arranged END(plane TC-END) is used by the application to close the transaction with other remote end...
If i am wrong plz comment anybody?

No. Plain TC_END might come

No. Plain TC_END might come into picture, when SCP decided to end the dialogue. That is a basic end. Whereas, if any one of the entities either SSP or SCP comes to know that the call can no longer exists due to some reason and state of the BCSM may become idle, then SSP set a pre-arrnaged end. In this case, SCP does not explicitly closes the dialouge as it did not arm any DPs in the BCSM.

I just want to know on what conditions, either one of the two entities will come to know about the pre-arranged end. This prearranged end cannot happen for low or no balance subscriber.

In my case, SSP has sent an IDP to SCP and SCP replies back in TC_continue message encapsulating CAP message RRBCSM event. In this RRBCSM event, only O_Disconnect(interr) and O_Abandon(notify&continue) DPs are armed. After this, SSP closes the dialouge with pre-arranged end. TCAP dialouge was cancelled due to opcode timeout.

TCAP Protocol level

Operation-name: RequestReportBSCMEvent
Primitive-type: Invoke
Application-context: [ 04 00 00 01 00 32 01 ]
Context-name: CAP-v2-gsmSSF-to-gsmSCF-AC
CAP Protocol version: V2

Destination Address GT: 09 01 09 09 07 00 04 09 08 09 07 02 [919970498972]
Destination Address SSN: 92 [CAP]
Destination Address NP: 01 [ISDN/TELEPHONY (REC. E.164/E.163)]
Destination Address NAI: 04 [INTERNATIONAL NUMBER]
Destination Address TT: 00 [TRANSLATION TYPE NOT USED]
Originating Address


CAP Protocol level

Primitive 1:


eventTypeBCSM = oAbandon
monitorMode = notifyAndContinue

eventTypeBCSM = oDisconnect
monitorMode = interrupted
sendingSideID = 01


I mean to say the same thing . I could have used Dialogure instead of transaction. This is applicapable for all the application layer protocols like CAMLE, MAP, INAP etc...

Hi guys,maybe it is too late

Hi guys,maybe it is too late - but here is some information about this: in principle we have situation when SSP/MSC and SCP are involved in handling of MO call. SCP implements some processing logic for this kind of call and while handling this call it needs to be asynchronously informed about some specific events from SSP. This is where the TC-CONTINUE with Invoke(RRBCSM) comes from. Now SCP internaly sets timer how long it is willing to wait for the event notification (implementation should have some default value - but you might perhaps configure this value too). This notification would be TC-CONTINUE with Invoke(ERBCSM) from SSP. While waiting for ERBCSM msg SCP might continue doing other call related handling, but important fact is that at this point SCP triggered SSP to inform him with ERBCSM msg in case any of those events specified in the RRBCSM occurs. Now imagine SCP has done all the handling it was supposed to do but there is still pending this operation timer. In case this operation timer expires and there is nothing else what SCP shall do it might terminate the dialogue with SSP. Termination of dialogue might be done in two ways:[list][*]SCP internally ends dialogue and does not inform SSP about this, no message is send out to SPP[*]SCP internally ends dialogue and informs SSP about this with TC-END message[/list]For CAPv3 you can find it in this [url=]3GPP TS 29.078 (version 4.9.0)[/url]. Go to the head:[list][*]12    Services assumed from lower layers[*]12.1    Services assumed from TC[*]12.1.2    gsmSSF gsmSCF interfaces[*]    Normal procedures[*]    gsmSCF to gsmSSF messages[/list] Here you will find this:  "The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSCF. When the gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and when the last associated operation timer expires, the dialogue is locally ended by means of a TC END request primitive with prearranged end.Alternatively, the sending of operations, leading to the termination of the relationship, by means of a TC END request primitive (basic end) is possible."