Acs For Tcap Users 20110324

Application Contexts for TCAP Users
"Application Context Name: The application context is the identifier of the application context proposed by the dialogue initiator or by the dialogue responder. An application context is an explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application-entities on a dialogue." [ITU Q.771, section 3.1.2.1, page 9]
Application Context (AC) names are carried by Transaction Capabilities Application Part (TCAP) messages on behalf of the application layers that define those names. AC names are meant to represent a wide variety of application- or user-defined conditions: They are used to represent a limit on the functionality and language used by an application processor.
Alpha Beta | | | | | Request... | | What about subscriber 40-11-16-2? | |----------------------------------------------------------------->| | | | | | Response... | | Tuesday, I think. | |<-----------------------------------------------------------------| | | | |
Figure 1: AC Free Request and Response Nonsense.
In the contrived example illustrated by Figure 1, an application at entity Alpha is asking an application at entity Beta, "Would you please tell me what you know about subscriber 40-11-16-2?" Without establishing an AC, how does the requestor know that the responder supports subscriber queries? Must an application within every entity in the network support those queries? Without establishing an AC, how does the requestor know that the responder understands the format of the subscriber identifier? Must all applications in the network that support subscriber queries also support the same request parameter format? Without establishing an AC, how does the requestor know that the responder will provide an answer that the requestor will understand? Must all applications in the network that support subscriber queries also support the same response parameter format?
An AC can easily represent a predefined subset of queries, and the parameter formats that should be used to request and respond to those queries. In an evolving system, AC names can also be used to support a version control mechanism, reflecting context modifications like expanded functionality, or changes to the required parameter formats.
2006-2011 Brian G. Holmes
Page 1 of 23

The application layers built upon TCAP declare and define AC name identifier values and their significance. This paper draws examples using GSM/UMTS Mobile Application Part (MAP) and ITU Intelligent Network Application Part (INAP) AC values. The significance of AC values in the application layers is discussed briefly in the later sections. The first part of this paper introduces the reader to AC names and AC negotiation, ignoring the fact that they are a syntactically optional feature of TCAP. The optional aspect of AC names will be discussed in later sections using MAP layer examples.
Figure 2: SS7 Stack.
Background Information
A TCAP message may include a dialogue portion as one of its first major parts. In most cases, the dialogue portion will include an application-context-name (i.e. an AC name). The application-context-name parameter carries an Object IDentifier (OID); a value of the Abstract Syntax Notation One (ASN.1) OBJECT IDENTIFIER type. An OID is reduced to a series of numeric values before it is encoded into its binary form. In this paper, OID values will be expressed as a series of decimal numbers separated by periods; the same format as the dot notation used by the OID Repository web site at http://www.oid-info.com/. TCAP messages come in five types: Unidirectional, Begin, End, Continue, and Abort. Unidirectional messages are not further addressed in this paper. All other requests are initiated using Begin messages. Dialogues initiated with a Begin message may be continued using a Continue message, terminated using an End or Abort message, or terminated without further communication. Operations are requested using an Invoke component. Positive responses are carried by Return Result components. Error conditions are described by Return Error components. Return Result and Return Error components are inappropriate in Begin messages, but Invoke components may be carried by Begin, Continue, and End messages. Message traffic for a dialogue evolves based upon the class of the operation or operations requested. The class is a matter for the application layer more than the TCAP layer, and is predefined based on the AC and operation code. The class of an invoked operation dictates the kind of component that might be used for a response:
Class 1: Response may report success or failure Class 2: Response may only be used to report failure Class 3: Response may only be used to report success Class 4: No response appropriate. (Return Result or Return Error) (Return Error only) (Return Result only)
Page 2 of 23

A dialogue is said to have a prearranged end when no operation responses are appropriate for any of the requests; both the requestor and responder know that the dialogue will end upon success and/or failure of the requested operations. Abort messages are used to report dialogue problems without regard to operations. The basics of AC utilization are best illustrated by basic dialogues that involve multiple messages, thus the first examples presented below presume that their operations are all of class 1. Keep in mind that the use of Invoke components carrying operations of the other classes is common in Begin, Continue, and End messages.
AC Negotiation Overview
The primary purpose of the TCAP layer is to manage a dialogue mechanism, wherein a response may be easily matched with the request that prompted its creation. A request cannot be fulfilled outside of the context of a dialogue. As such, the TCAP layer will attempt to establish a dialogue before it attempts to fulfill a request. The AC carried in the dialogue portion of a Begin message is used by the TCAP layer to ask its application whether or not the dialogue can be established. If an application supports a given AC then it may ask the TCAP layer to establish the dialogue if it needs to communicate with the requestor. The following diagrams contain simplified examples of AC negotiation. In each of them, an application at entity Alpha is requesting that an application at entity Beta perform a MAP operation.
Alpha Beta | | | | | Begin message asks... | | Do you support AC 0.4.0.0.1.0.1.4? | | If so, would you please invoke operation 2? | (a) |----------------------------------------------------------------->| (a) | | | | | Abort message answers... | | No, I always reject AC 0.4.0.0.1.0.1.4. | | You might want to try AC 0.4.0.0.1.0.1.3. | (b) |<-----------------------------------------------------------------| (b) | | | |
Figure 3: AC Negotiation With a Negative Response in an Abort Message. 1
The ACs and operation codes are specified in numeric form to illustrate the view that TCAP has of them. The application layer and application may know that operation code 2 in a dialogue with AC 0.4.0.0.1.0.1.4 represents the GSM MAP updateLocation operation in networkLocUpContext version 4, but the TCAP layer does not.
Page 3 of 23

In Figure 3, entity Alpha sends a request to entity Beta to invoke operation 2 within AC 0.4.0.0.1.0.1.4. Beta sends a rejection to Alpha because it does not support that AC. Beta also suggested an alternative AC to Alpha using its Abort message.
"If the proposed application-context-name can be supported by the responding entity the dialogue continues on this basis otherwise the dialogue is refused and the initiating user needs to start a new dialogue, which involves another application-context-name which requires less communication capabilities but provides similar functionality (if possible)." [3GPP 29.002, version 7.1.0, section 5.2.1, page 37]
The aborted dialogue of Figure 3 might be followed directly by either of the two dialogues that follow.
Alpha Beta | | | | | Begin message asks... | | Do you support AC 0.4.0.0.1.0.1.3? | | If so, would you please invoke operation 2? | (a) |----------------------------------------------------------------->| (a) | | | | | End message answers... | | Yes, I support AC 0.4.0.0.1.0.1.3. | | Here is your response to operation 2. | (b) |<-----------------------------------------------------------------| (b) | | | |
Figure 4: AC Negotiation With a Positive Response in an End Message. 2
In Figure 4, entity Alpha sends a request to entity Beta to invoke operation 2 within AC 0.4.0.0.1.0.1.3. Beta sends a response to Alpha confirming its support of that AC, and containing response data for operation 2. TCAP also allows Beta to answer the request using an alternative AC in its response message. Note that the response data in Figure 4 might still represent a positive or negative result; a TCAP Return Result or Return Error component. In either case, it is a valid response within an established context.
Application layer view: Operation code 2 in AC 0.4.0.0.1.0.1.3 represents the GSM MAP updateLocation operation in networkLocUpContext version 3.
Page 4 of 23
Alpha Beta | | | | | Begin message asks... | | Do you support AC 0.4.0.0.1.0.1.3? | | If so, would you please invoke operation 2? | (a) |----------------------------------------------------------------->| (a) | | | | | Continue message answers and asks... | | Yes, I support AC 0.4.0.0.1.0.1.3. | | Would you please invoke operation 7? | (b) |<-----------------------------------------------------------------| (b) | | | | | Continue message answers... | | Here is your response to operation 7. | (c) |----------------------------------------------------------------->| (c) | | | | | End message answers... | | Here is your response to operation 2. | (d) |<-----------------------------------------------------------------| (d) | | | |
Figure 5: AC Negotiation With a Positive Response in a Continue Message.3
A response may also be carried in a Continue message if the procedure associated with the operation allows or dictates it. Figure 5 illustrates the fact that some operations require the responding entity to temporarily reverse rolls with the requesting entity within the same dialogue. The dialogue is still established by the first message from entity Beta to entity Alpha, but now that message is a Continue message. TCAP also allows Beta to answer the request using an alternative AC in its first Continue message.
Alpha Beta | | | | | Begin message asks... | | Do you support AC 0.0.17.1228.2.3.4? | | If so, would you please invoke operation 0? | (a) |----------------------------------------------------------------->| (a) | | | | | Continue message answers and asks... | | Yes, I support AC 0.0.17.1228.2.3.4. | | Would you please invoke operation 20? | (b) |<-----------------------------------------------------------------| (b) | | | |
Figure 6: Prearranged End with a Continue Message.4
Figure 6 illustrates the use of class 2 operations in a dialogue that has a prearranged end.
3 Application layer view: Operation code 2 in AC 0.4.0.0.1.0.1.3 represents the GSM MAP updateLocation operation in networkLocUpContext version 3. Operation code 7 represents the insertSubscriberData operation in that same context. Application layer view: Operation code 0 in AC 0.0.17.1228.2.3.4 represents the ITU INAP initialDP operation in the Capability Set 2 ssf2scfGenericAC. Operation code 20 represents the connect operation in that same context.
Page 5 of 23

The prearranged end mechanism makes it possible for two entities to engage in a completely one-sided dialogue while still using the TCAP messages whose names imply a two-sided conversation. One entity can send a Begin message that is never responded to. As Figure 6 shows, the other entity can react to that Begin message by sending a Continue message that may never be responded to. Alpha invokes the dialogue with a class 2 operation. Nothing in the Invoke component expresses the class of the operation, but the application layers at Alpha and Beta will know the appropriate class based on the AC and operation code. It is inappropriate for Beta to respond to that Invoke component with anything but a Return Error component. Beta reacts to the operation in the Begin message by invoking a class 2 operation of its own. Alpha can only respond to the second operation by describing error conditions, but it will only be able to do that if the dialogue remains open. For that reason, Beta sends the second operation in a Continue message. If Alpha has no error conditions to respond with then the dialogue terminates quietly with a prearranged end.
Dialogue Portion Confusion

Readers of the ITU recommendations should take care not to be confused by the similar names used to describe dialogue and message parts that serve distinct purposes. The Application Protocol Data Unit (APDU) names are misleading outside of the context of the recommendation in which they were originally defined. The problem is further complicated by the TCAP-specific dialogue names that are attached to them: Dialogue Request (a.k.a. AARQ) information should only appear in a Begin message; Dialogue Response (a.k.a. AARE) information should appear in the first End or Continue message of a dialogue when an AC is supported, or in an Abort message when it is not; Dialogue Abort (a.k.a. ABRT) information is supposed to be used to report poorly formed Dialogue Request or Dialogue Response information, and should only appear in an Abort message.
All of this is complicated by the fact that TCAP syntax is defined in a loosey-goosey manner, where many syntactically correct message formats are semantically invalid, and dialogue information was retrofit into that syntax.
MAP AC Usage
The GSM/UMTS MAP specifications define many ACs. Each MAP AC is associated with one or more operation package, and each operation package is associated with one or more operation. Processing priorities are also assigned based on AC.
Page 6 of 23

gprsLocationUpdateContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { gprsLocationUpdatingPackage-v3} RESPONDER CONSUMER OF { subscriberDataMngtPackage-v3 | tracingPackage-v3} ID {map-ac gprsLocationUpdate(32) version3(3)} }
gprsLocationInfoRetrievalContext-v4 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GGSN INITIATOR CONSUMER OF { gprsInterrogationPackage-v4} ID {map-ac gprsLocationInfoRetrieval(33) version4(4)} }
Figure 7: Two UMTS MAP AC Declarations.

[3GPP 29.002, version 7.1.0, section 17.3.2, page 302]
The map-ac value referenced in the ASN.1 of Figure 7 represents the OID root/prefix of every MAP AC. It is defined in the MAP-ApplicationContexts module. It reduces to 0.4.0.0.1.0 before it is encoded as an OBJECT IDENTIFIER.
"A version negotiation mechanism based on the use of an application-context-name is used to negotiate the protocol version used between two entities for supporting a MAP-user signalling procedure." [3GPP 29.002, version 7.1.0, section 5.2.1, page 37]
Figure 7 also illustrates the format of all of the MAP AC OIDs: The map-ac prefix followed by a digit that represents the general AC, which is followed by a digit that represents the AC version. Version control is explicitly built into each MAP AC in this way. Allotting a version digit to each AC OID simplifies the process of AC negotiation: Start with the highest AC version. If one AC version is rejected by a responding entity then try the next lower version number. Continue to check AC versions until one is accepted.
"A method should be used to minimise the number of protocol fall-backs which would occur sometimes if the highest supported AC-Name were always the one selected by GSM entities when initiating a dialogue." [3GPP 29.002, version 7.1.0, section 5.2.2, page 37]
The MAP specification also recommends that every application maintain a database where entities are associated with the AC versions that they support.
One Unspoken MAP AC Version

The history of GSM/UMTS MAP predates support for AC names in ITU TCAP. As such, ACs were not defined in the phase one MAP specification. ACs were later defined in the phase two specification. Thereafter, the operations defined in the phase one specification were assumed to be associated with ACs of version one.
Page 7 of 23

After TCAP was updated to support AC names, MAP was free to adopt their use, but the older versions of TCAP and MAP were still in use. To allow both old and new versions to coexist in the same network, MAP applications were designed to assume that any TCAP dialogue that was initiated without an AC name carried information for some AC at version one.
"A node supporting the 1988 version of TC will not understand the APDUs associated with the Application Context generated by a node conforming to the 1992 Recommendation (or any latter version) and will therefore abort the transaction." [ITU Q.775, section 3.3.4, page 30]
While new TCAP applications were built to handle AC names, old TCAP applications did not need to change. When an application supported by TCAP with AC names attempted to initiate a dialogue with an application supported by TCAP without AC names the latter would naturally abort the dialogue because it could not decode the entire message.
"MAP requests the transfer of the application-context-name by TC only for those contexts which do not belong to the so-called 'version one context set'." [3GPP 29.002, version 7.1.0, section 14.4, page 225]
In addition, a MAP AC at version one should not be encoded as an AC name in a TCAP message, with one exception: When a responding entity rejects a proposed AC (aborting the dialogue), and also wants to exercise its option of proposing another AC, it may explicitly propose an AC at version one. As a result of the special handling of ACs at version one, new MAP ACs are assigned versions greater-than one. For example, the anyTimeInfoEnquiryContext does not appear in the phase one or phase two specifications, and was first defined at version three. The reader should take care not to confuse an AC version number with a MAP phase number because they are not related. Also, these AC version numbers are not used by protocols other than GSM/UMTS MAP.
INAP And MAP AC Value Samples

An initialDP operation might appear in messages of the ETSI INAP, ITU INAP, or 3GPP CAP protocols, as well as one or two private varieties of these. The parameter profile of these initialDP operations differs in some ways. As such, applications base their support for the initialDP operation on the AC of the dialogue in which it is carried.
Page 8 of 23

OID Dot Notation
0.0.17.1218.1.0.0 0.0.17.1228.2.3.4 0.0.17.1238.3.4.0 0.0.17.1248.3.4.0
Specification ITU-T INAP CS1 ITU-T INAP CS2 ITU-T INAP CS3 ITU-T INAP CS4
OID Name And Number Notation {itu-t(0) recommendation(0) q(17) q1218(1218) scfssf-srf-objects(1) generic-ssf-to-scf(0) version1(0)} {itu-t(0) recommendation(0) q(17) q1228(1228) cs2(2) ac(3) ssf-scfGenericAC(4)} {itu-t(0) recommendation(0) q(17) q1238(1238) ac(3) ssf-scfGenericAC(4) version1(0)} {itu-t(0) recommendation(0) q(17) q1248(1248) ac(3) ssf-scfGenericAC(4) version1(0)}
0.4.0.0.1.21.3.4
{itu-t(0) identified-organization(4) etsi(0) 3GPP CAP Phase 3 mobileDomain(0) gsm-Network(1) cAP3OE(21) ac(3) gsmSSF-scfGenericAC(4)} {itu-t(0) identified-organization(4) etsi(0) 3GPP CAP Phase 4 mobileDomain(0) gsm-Network(1) cap4OE(23) ac(3) gsmSSF-scfGenericAC(4)} ETSI INAP CS15 ETS 300 374-1 (1994-09) ETSI INAP CS16 www.oid-info.com ETSI INAP CS2 EN 301 140-1 V1.3.4 (1999-06) ETSI INAP CS3 {itu-t(0) identified-organization(4) etsi(0) inDomain(1) in-Network(1) ac(1) cs1-ssp-to-scp(0) version1(0)} {itu-t(0) identified-organization(4) etsi(0) inDomain(1) in-Network(1) cs1(1) ac(1) cs1-ssp-toscp(0) version1(0)} {itu-t(0) identified-organization(4) etsi(0) inDomain(1) in-Network(1) cs2(20) ac(3) ssfscfGenericAC(4)} {itu-t(0) identified-organization(4) etsi(0) inDomain(1) in-Network(1) cs3(30) ac(3) ssfscfGenericAC(4) version1(0)}
0.4.0.0.1.23.3.4
0.4.0.1.1.1.0.0
0.4.0.1.1.1.1.0.0
0.4.0.1.1.20.3.4
0.4.0.1.1.30.3.4.0
Table 1: AC Values Associated With initialDP Operations
Table 1 presents AC values for dialogues in which an initialDP operation might be carried. One number in each OID value is underlined above to show that these OID values differ early in the number sequence although they represent related ACs. An ITU or ETSI INAP Capability Set (CS) is much like a GSM CAP or MAP Phase.
5 6
AC 0.4.0.1.1.1.0.0 is defined by ETSI ETS 300 374 for use with the CS1 initialDP operation, but may be errant. AC 0.4.0.1.1.1..1.0.0 is a recommended replacement for AC 0.4.0.1.1.1.0.0 as per http://www.oidinfo.com/get/0.4.0.1.1.1 "ETSI ETS 300 374... defines ACs with OIDs beginning... {itu-t(0) identifiedorganization(4) etsi(0) inDomain(1) in-network(1) ac(1)}. It is believed that... cs1(1) is missing in front... [of] ac(1). "
Page 9 of 23

OID Dot Notation Specification OID Name And Number Notation {itu-t(0) identified-organization(4) etsi(0) mobileDomain(0) gsm-Network(1) applicationContext(0) networkLocUp(1) version1(1)}
0.4.0.0.1.0.1.1
0.4.0.0.1.0.16.1
GSM MAP Phase 1 3GPP 09.02 version {itu-t(0) identified-organization(4) etsi(0) 3.11.0 (1995-04)7 mobileDomain(0) gsm-Network(1) applicationContext(0) subscriberDataMngt(16) version1(1)} {itu-t(0) identified-organization(4) etsi(0) mobileDomain(0) gsm-Network(1) applicationContext(0) networkLocUp(1) version2(2)}
0.4.0.0.1.0.1.2
0.4.0.0.1.0.16.2
GSM MAP Phase 2 3GPP 09.02 version {itu-t(0) identified-organization(4) etsi(0) 4.19.1 (2000-12) mobileDomain(0) gsm-Network(1) applicationContext(0) subscriberDataMngt(16) version2(2)} {itu-t(0) identified-organization(4) etsi(0) mobileDomain(0) gsm-Network(1) applicationContext(0) networkLocUp(1) version3(3)} GSM/UMTS MAP Phase 2+ 3GPP 29.002 version 9.0.0 (2009-12) {itu-t(0) identified-organization(4) etsi(0) mobileDomain(0) gsm-Network(1) applicationContext(0) subscriberDataMngt(16) version3(3)} {itu-t(0) identified-organization(4) etsi(0) mobileDomain(0) gsm-Network(1) applicationContext(0) gprsLocationUpdate(32) version3(3)}
0.4.0.0.1.0.1.3
0.4.0.0.1.0.16.3
0.4.0.0.1.0.32.3
Table 2: AC Values Associated With insertSubscriberData Operations.
Table 2 shows the AC values associated with the insertSubscriberData operation; the message described by Figure 18 makes use of one of these. The table contains three version of the networkLocUp and subscriberDataMngt contexts, and illustrates the use of version numbers at the end of MAP AV values. The table also contains one gprsLocationUpdate context; the first and only version given a version number of 3. Please note that the AC version numbers do not coincide with the MAP Phase numbers even though they seem to in the table above. The Phase 2+ specification contains ACs with version number 2, 3, and 4.
The GSM MAP Phase 1 specification predates the TCAP AC mechanism. The use of GSM MAP AC values for Phase 1 is described in the Phase 2 documentation.
Page 10 of 23

XERT Examples
The following message examples are presented in the XML Encoding Rules for Translation (XERT) format. MAP data is usually encoded into a binary format called the Basic Encoding Rules (BER) for ASN.1. The XERT format was designed to represent data encoded using the BER format in a way that allows translation back into its original BER format. The XERT format easily represents the message parameter hierarchy, without requiring the reader to work through the binary encoding. Textual hexadecimal (a.k.a. Thex) data is also provided for those who want to examine the message structure in tools of their own. All of the address data carried by the example messages was created solely for the purposes of illustration. No attempt was made to make that data resemble real-world addresses. The initial requests made in Figure 3, Figure 4, and Figure 5 were MAP updateLocation operations; AC 0.4.0.0.1.0.1 and operation code 2. MAP data for updateLocation requests is carried within Invoke components of Begin messages. The location update procedure is used by a Visitor Location Register (VLR) application to determine the functionality it should support for a mobile subscriber, when that subscriber has entered into the area that it serves. The VLR initiates a dialogue with the subscriber's Home Location Register (HLR) in order to invoke an updateLocation operation. In the course of a normal dialogue, the HLR will provide subscription information to the VLR through use of insertSubscriberData operations. The following figures will illustrate the use of TCAP Abort, End, and Continue messages to respond directly to that initial request. The Abort message is used to signal a problem with the dialogue itself. The End message is used to terminate the dialogue with an error message. The Continue message is used to establish the dialogue and to resume the procedure.
Page 11 of 23

<?xml version='1.0' encoding='UTF-8'?>  <xertion> <MessageType> <begin> <otid>1111</otid> <dialoguePortion> <encoding> <single-ASN1-type> <dialogueRequest> <application-context-name> 0.4.0.0.1.0.1.4 </application-context-name> </dialogueRequest> </single-ASN1-type> </encoding> </dialoguePortion> <components> <item> <invoke> <invokeID>1</invokeID> <operationCode> <localValue>2</localValue> </operationCode> <parameter tag='30'> <tlv tag='04'>21436500000000F1</tlv> <tlv tag='81' encoding='octetString'>1122330001</tlv> <tlv tag='04'>1122330002</tlv> </parameter> </invoke> </item> </components> </begin> </MessageType> </xertion>
Figure 8 [Figure 3.a]: Requesting an Unsupported AC (XERT).
# # A begin message with a request for an unsupported AC. # 623B480211116B11280FA00D600BA109 0607040000010001046C22A120020101 0201023018040821436500000000F181 05112233000104051122330002
Figure 9 [Figure 3.a]: Requesting an Unsupported AC (BER Thex).
The TCAP application-context-name is carried in the dialoguePortion of a message. In this way, the responding entity need not decode the components section of the message until the dialogue is found to be acceptable. The message of Figure 8 is thus shown decoded using only TCAP layer information; MAP parameters are presented using generic tlv elements.
Page 12 of 23

<?xml version='1.0' encoding='UTF-8'?>  <xertion> <MessageType> <abort> <dtid>1111</dtid> <reason> <u-abortCause> <direct-reference>0.0.17.773.1.1.1</direct-reference> <encoding> <single-ASN1-type> <dialogueResponse> <protocol-version>version1</protocol-version> <application-context-name> 0.4.0.0.1.0.1.3 </application-context-name> <result>reject-permanent</result> <result-source-diagnostic> <dialogue-service-user> application-context-name-not-supported </dialogue-service-user> </result-source-diagnostic> </dialogueResponse> </single-ASN1-type> </encoding> </u-abortCause> </reason> </abort> </MessageType> </xertion>
Figure 10 [Figure 3.b]: Rejecting an Unsupported AC (XERT).
# # An abort message with a response to an unsupported AC. # 6730490211116B2A2828060700118605 010101A01D611B80020780A109060704 000001000103A203020101A305A10302 0102
Figure 11 [Figure 3.b]: Rejecting an Unsupported AC (BER Thex).
The messages of Figure 8 through Figure 11 correspond to the request and response of Figure 3: The begin message carries an AC that is not supported by the responding application, so the responding entity issues an abort message. The message not only provides information describing why the dialogue was aborted, but also suggests a related AC for the requesting entity to use. The map-ac.1.4 AC was used for this example because it is not defined within any of the current MAP specifications; 3GPP 29.002 version 7.1.0 . While it is true that an AC has to be defined before it can be supported, not all defined ACs are supported by every entity. The example would still have been valid without regard to the AC name it used.
Page 13 of 23

<?xml version='1.0' encoding='utf-8'?>   <xertion> <MessageType> <begin> <otid>2222</otid> <dialoguePortion> <encoding> <single-ASN1-type> <dialogueRequest> <application-context-name> 0.4.0.0.1.0.1.3 </application-context-name> </dialogueRequest> </single-ASN1-type> </encoding> </dialoguePortion> <components> <item> <invoke> <invokeID>1</invokeID> <operationCode> <localValue>2</localValue> </operationCode> <UpdateLocationArg> <imsi>21436500000000F1</imsi> <msc-Number>1122330001</msc-Number> <vlr-Number>1122330002</vlr-Number> </UpdateLocationArg> </invoke> </item> </components> </begin> </MessageType> </xertion>
Figure 12 [Figure 4.a]: Attempted Roaming for a Limited Subscriber (XERT).
# # A begin message with an updateLocation request for a limited subscriber. # 623B480222226B11280FA00D600BA109 0607040000010001036C22A120020101 0201023018040821436500000000F181 05112233000104051122330002
Figure 13 [Figure 4.a]: Attempted Roaming for a Limited Subscriber (BER Thex).
The components section of the request message in Figure 12 are decoded to show that the updateLocation request relates to a mobile subscriber within the area served by an MSC and VLR. The MAP information is shown here because it will be required by the responding application in order for it to answer the request. The components section is almost the same as the one carried by the message in Figure 8 and Figure 9.
Page 14 of 23

<?xml version='1.0' encoding='UTF-8'?>  <xertion> <MessageType> <end> <dtid>2222</dtid> <dialoguePortion> <direct-reference>0.0.17.773.1.1.1</direct-reference> <encoding> <single-ASN1-type> <dialogueResponse> <application-context-name> 0.4.0.0.1.0.1.3 </application-context-name> <result>accepted</result> <result-source-diagnostic> <dialogue-service-user>null</dialogue-service-user> </result-source-diagnostic> </dialogueResponse> </single-ASN1-type> </encoding> </dialoguePortion> <components> <item> <returnError> <invokeID>1</invokeID> <errorCode> <localValue>8</localValue> </errorCode> <RoamingNotAllowedParam> <roamingNotAllowedCause> plmnRoamingNotAllowed </roamingNotAllowedCause> </RoamingNotAllowedParam> </returnError> </item> </components> </end> </MessageType> </xertion>
Figure 14 [Figure 4.b]: Responding When Roaming is Not Allowed (XERT).
# # An end message with a roamingNotAllowed response. # 6439490222226B262824060700118605 010101A0196117A10906070400000100 0103A203020100A305A1030201006C0B A3090201010201080A0100
Figure 15 [Figure 4.b]: Responding When Roaming is Not Allowed (BER Thex).
The messages of Figure 12 through Figure 15 correspond to the request and response of Figure 4: The Begin message carries an AC that is supported by the responding application, but the identified subscriber is not allowed to roam, so the responding entity establishes the dialogue, and issues a Return Error component within the AC.
Page 15 of 23

Remember that Figure 4 is entitled "AC Negotiation With a Positive Response in an End Message." That title still matches the example above because the end message carries a positive response with regard to establishment of the dialogue. The error described in the components section of the end message is a MAP issue, and MAP issues are not raised until after a TCAP dialogue is established.
<?xml version='1.0' encoding='utf-8'?> 
Figure 16 [Figure 5.a]: An updateLocation/Invoke/Begin Message (XERT).
# # A begin message with an updateLocation request. # 623B480233336B11280FA00D600BA109 0607040000010001036C22A120020101 0201023018040821436500000000F281 05112233000104051122330002
Figure 17 [Figure 5.a]: An updateLocation/Invoke/Begin Message (BER Thex).
The Begin message above will initiate a dialogue that will be established by the message that follows, and illustrate normal support for the updateLocation operation.
Page 16 of 23

The messages of Figure 16 through Figure 23 correspond to the requests and responses of Figure 5: The Begin message carries an AC that is supported by the responding application. The updateLocation operation procedure dictates an insertSubscriberData operation be completed between the same applications, so the dialogue is established using a Continue message that carries that request.
<?xml version='1.0' encoding='UTF-8'?>  <xertion> <MessageType> <continue> <otid>4444</otid> <dtid>3333</dtid> <dialoguePortion> <direct-reference>0.0.17.773.1.1.1</direct-reference> <encoding> <single-ASN1-type> <dialogueResponse> <protocol-version>version1</protocol-version> <application-context-name> 0.4.0.0.1.0.1.3 </application-context-name> <result>accepted</result> <result-source-diagnostic> <dialogue-service-user>null</dialogue-service-user> </result-source-diagnostic> </dialogueResponse> </single-ASN1-type> </encoding> </dialoguePortion> <components> <item> <invoke> <invokeID>4</invokeID> <operationCode> <localValue>7</localValue> </operationCode> <InsertSubscriberDataArg lengthForm='indefinite'> <msisdn>918888888888F8</msisdn> <category>0A</category> <subscriberStatus>serviceGranted</subscriberStatus> <bearerServiceList> <item>17</item> </bearerServiceList> <teleserviceList> <item>11</item> <item>21</item> <item>22</item> </teleserviceList> <provisionedSS lengthForm='indefinite'> <item> <forwardingInfo> <ss-Code>21</ss-Code> <forwardingFeatureList> <item> <basicService> <ext-Teleservice>10</ext-Teleservice>
Page 17 of 23

</basicService> <ss-Status>04</ss-Status> </item> <item> <basicService> <ext-BearerService>10</ext-BearerService> </basicService> <ss-Status>04</ss-Status> </item> </forwardingFeatureList> </forwardingInfo> </item> <item> <forwardingInfo> <ss-Code>29</ss-Code> <forwardingFeatureList> <item> <basicService> <ext-Teleservice>10</ext-Teleservice> </basicService> <ss-Status>07</ss-Status> <forwardedToNumber>9177777777777777</forwardedToNumber> <forwardingOptions>04</forwardingOptions> </item> <item> <basicService> <ext-BearerService>10</ext-BearerService> </basicService> <ss-Status>07</ss-Status> <forwardedToNumber>9166666666666666</forwardedToNumber> <forwardingOptions>04</forwardingOptions> </item> </forwardingFeatureList> </forwardingInfo> </item> </provisionedSS> </InsertSubscriberDataArg> </invoke> </item> </components> </continue> </MessageType> </xertion>
Figure 18 [Figure 5.b]: An insertSubscriberData/Invoke/Continue Message (XERT).
# # A continue message with an insertSubscriberData request. # 6581AD48024444490233336B2A282806 0700118605010101A01D611B80020780 A109060704000001000103A203020100 A305A1030201006C77A1750201040201 0730808107918888888888F882010A83 0100A403040117A60904011104012104 0122A780A01504012130103006830110 8401043006820110840104A02F040129 302A3013830110840107850891777777 77777777860104301382011084010785 08916666666666666686010400000000
Figure 19 [Figure 5.b]: An insertSubscriberData/Invoke/Continue Message (BER Thex).
Page 18 of 23

The message above seems very long, but it contains only a subset of the kinds of subscription data that may be passed between an HLR and VLR. It is most common for a dialogue that is initiated with an updateLocation operation to involve two insertSubscriberData operations. One insertSubscriberData operation is completed before the next is invoked. No limit is placed on the number of insertSubscriberData operations used; that number used depends upon the subscription options that are supported by the HLR and VLR.
<?xml version='1.0' encoding='UTF-8'?> 
Figure 20 [Figure 5.c]: An insertSubscriberData/ReturnResultLast/End Message (XERT).
# # A continue message with an unidentified response. # 650F48023333490244446C05A2030201 01
Figure 21 [Figure 5.c]: An insertSubscriberData/ReturnResultLast/End Message (BER Thex).
Responses for insertSubscriberData operations communicate the aspects of a subscription that a VLR cannot support. If the VLR supports all aspects of the subscription that it was sent in the Invoke component then it's response should be empty; note the absence of MAP data in the response message above. The components section of the message must still identify the component that is being responded to, but it does not identify the operation.
Page 19 of 23

<?xml version='1.0' encoding='utf-8'?>  <xertion> <MessageType> <end> <dtid>3333</dtid> <components> <item> <returnResultLast> <invokeID>1</invokeID> <result> <operationCode> <localValue>2</localValue> </operationCode> <UpdateLocationRes> <hlr-Number>010203040506070809</hlr-Number> </UpdateLocationRes> </result> </returnResultLast> </item> </components> </end> </MessageType> </xertion>
Figure 22 [Figure 5.d]: An updateLocation/ReturnResultLast/End Message (XERT).
# # An end message with an updateLocation response. # 641D490233336C17A215020101301002 0102300B0409010203040506070809
Figure 23 [Figure 5.d]: An updateLocation/ReturnResultLast/End Message (BER Thex).
The updateLocation result component identifies the HLR that serves the subscriber, and is carried by an End message. The INAP examples that follow are presented using only TCAP translations because the utilities used to create XERT data do not yet handle the INAP protocol.
Page 20 of 23

<?xml version='1.0' encoding='utf-8'?>  <xertion> <MessageType> <begin> <otid>5555</otid> <dialoguePortion> <direct-reference>0.0.17.773.1.1.1</direct-reference> <encoding> <single-ASN1-type> <dialogueRequest> <protocol-version>version1</protocol-version> <application-context-name> 0.0.17.1228.2.3.4 </application-context-name> </dialogueRequest> </single-ASN1-type> </encoding> </dialoguePortion> <components lengthForm='indefinite'> <item> <invoke> <invokeID>0</invokeID> <operationCode> <localValue>0</localValue> </operationCode> <parameter tag='30'> <tlv tag='80' encoding='octetString'>00FF77</tlv> <tlv tag='82' encoding='octetString'>01020304050607</tlv> </parameter> </invoke> </item> </components> </begin> </MessageType> </xertion>
Figure 24 [Figure 6.a]: An initialDP/Invoke/Begin Message (XERT).

# # Class 2 Operation Invoked in a Begin Message. # 6240480255556B1E281C060700118605 010101A011600F80020780A109060700 11894C0203046C80A116020100020100 300E800300FF77820701020304050607 0000
Figure 25 [Figure 6.a]: An initialDP/Invoke/Begin Message (BER Thex).
The initialDP operation is triggered by events in the network. It is a class 2 operation to which there is no returned result. Entities that receive an initialDP operation react to it in different ways. One normal reaction is to send a connect operation back to the initiating entity.
Page 21 of 23

<?xml version='1.0' encoding='utf-8'?>  <xertion> <MessageType> <continue> <otid>6666</otid> <dtid>5555</dtid> <dialoguePortion> <direct-reference>0.0.17.773.1.1.1</direct-reference> <encoding> <single-ASN1-type> <dialogueResponse> <protocol-version>version1</protocol-version> <application-context-name> 0.0.17.1228.2.3.4 </application-context-name> <result>accepted</result> <result-source-diagnostic> <dialogue-service-user>null</dialogue-service-user> </result-source-diagnostic> </dialogueResponse> </single-ASN1-type> </encoding> </dialoguePortion> <components> <item> <invoke> <invokeID>0</invokeID> <operationCode> <localValue>20</localValue> </operationCode> <parameter class='UNIVERSAL' number='16'> <tlv class='Context-Specific' number='0'> <tlv class='UNIVERSAL' number='4'>8390050040477641880F</tlv> </tlv> </parameter> </invoke> </item> </components> </continue> </MessageType> </xertion>
Figure 26 [Figure 6.b]: A connect/Invoke/Continue Message (XERT).

# # Class 2 Operation Invoked in a Continue Message. # 654E48026666490255556B2A28280607 00118605010101A01D611B80020780A1 0906070011894C020304A203020100A3 05A1030201006C18A116020100020114 300EA00C040A8390050040477641880F
Figure 27 [Figure 6.b]: A connect/Invoke/Continue Message (BER Thex).
The connect operation is also a class 2 operation to which there is no appropriate returned result. Alpha has the option of responding with a Return Error component because the Invoke component was sent in a Continue message rather than an End message.
Page 22 of 23

Additional Information
Brian Holmes has been working with TCAP since 1999. He has written TCAP message handlers, guided development of an independent TCAP layer, and worked with several application layer protocols carried in TCAP. Brian has developed ASN.1 parsers to produce databases for real-time software that is used to identify and manipulate GSM mobility management messages. He has also developed a suite of utilities that use similar databases produced from ASN.1 definitions to translate binary messages to and from the XERT format. The ber2xer4tcap, ber2xer4map, xer2ber4tcap, and xer2ber4map utilities were used to generate the examples in XERT and Thex formats. Those examples were color-coded using the xml2html utility. These utilities and more are described on the berasno.com web site. The Application Contexts for TCAP Users paper was originally published on 12 June 2006. This revision was enhanced to include class 2 INAP operation examples on 24 March 2011, and made available at http://www.berasno.com/briefcase/.
Page 23 of 23

Acs For Tcap Users 20110324

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Acs For Tcap Users 20110324

Uploaded by

Copyright:

Available Formats

Application Contexts for TCAP Users

Figure 1: AC Free Request and Response Nonsense.

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 2: SS7 Stack.

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 3: AC Negotiation With a Negative Response in an Abort Message. 1

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 4: AC Negotiation With a Positive Response in an End Message. 2

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 5: AC Negotiation With a Positive Response in a Continue Message.3

Figure 6: Prearranged End with a Continue Message.4

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Dialogue Portion Confusion

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 7: Two UMTS MAP AC Declarations.

One Unspoken MAP AC Version

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

INAP And MAP AC Value Samples

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Table 1: AC Values Associated With initialDP Operations

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Table 2: AC Values Associated With insertSubscriberData Operations.

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 8 [Figure 3.a]: Requesting an Unsupported AC (XERT).

Figure 9 [Figure 3.a]: Requesting an Unsupported AC (BER Thex).

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 10 [Figure 3.b]: Rejecting an Unsupported AC (XERT).

Figure 11 [Figure 3.b]: Rejecting an Unsupported AC (BER Thex).

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 12 [Figure 4.a]: Attempted Roaming for a Limited Subscriber (XERT).

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 14 [Figure 4.b]: Responding When Roaming is Not Allowed (XERT).

# # An end message with a roamingNotAllowed response. # 6439490222226B262824060700118605 010101A0196117A10906070400000100 0103A203020100A305A1030201006C0B A3090201010201080A0100

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 16 [Figure 5.a]: An updateLocation/Invoke/Begin Message (XERT).

# # A begin message with an updateLocation request. # 623B480233336B11280FA00D600BA109 0607040000010001036C22A120020101 0201023018040821436500000000F281 05112233000104051122330002

Figure 17 [Figure 5.a]: An updateLocation/Invoke/Begin Message (BER Thex).

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 18 [Figure 5.b]: An insertSubscriberData/Invoke/Continue Message (XERT).

Figure 19 [Figure 5.b]: An insertSubscriberData/Invoke/Continue Message (BER Thex).

2006-2011 Brian G. Holmes

Application Contexts for TCAP Users

Figure 20 [Figure 5.c]: An insertSubscriberData/ReturnResultLast/End Message (XERT).