You are here

Component Portion: Parameter Tag Ambiguity

6 posts / 0 new
Last post
cmdcenter
Component Portion: Parameter Tag Ambiguity

First let's look at the definition of Parameter Tag from "[b]Q.773 - Transaction capabilities formats and encoding[/b]" document:

4.2.2.4 Parameter tag
The Parameter tag shall be any valid ASN.1 tag, depending on the type of the parameter supplied. It can indicate either a primitive or a constructor element and refer to any of the defined tag classes. When the parameter element is a collection of several information elements, the associated data type shall be derived from the Sequence, SequenceOf, Set or SetOF types (see Table 23).

[b]Table 23/Q.773 – Coding of Sequence and Set Tags[/b]
------------------H G F E D C B A
Sequence Tag ---- 0 0 1 1 0 0 0 0 (0x30)
Set Tag --------- 0 0 1 1 0 0 0 1 (0x31)

Given the above definition, I have seen in some cases the absence of Parameter tag (sequence or set) even though there had been more than one MAP parameters. I wonder when the Parameter Tag is optional and when is mandatory?

Next question:
If you look at the definition of MAP operations in "[b]3GPP TS 29.002[/b] document", you will see that their definition usually starts with a sequence tag. e.g. here is the definition of [b]Cancel Location[/b] operation:

[size=10]CancelLocationArg ::= [3] SEQUENCE {
identity Identity,
cancellationType CancellationType OPTIONAL,
extensionContainer ExtensionContainer OPTIONAL,
...,
typeOfUpdate [0] TypeOfUpdate OPTIONAL }[/size]

As can be seen, this operation starts with an implicit sequence tag (0xA3), has one mandatory and three optional parameters. The question is how is this sequence tag (0xA3) different from Parameter Tag (0x30). When is this sequence tag optional and when is it mandatory? I have seen many Cancel Location parameters that start only with 0x30 tag, and many of them that start with only 0xA3 tag. Is it possible for parameters to start with two subsequent 0x30 and 0xA3 tags? Has it been clearly explained in any document?
Any response would be greatly appreciated!

p.s. [i]Does the version of application context (2 or 3) have anything to do with the existence or absence of sequence tag?[/i]

Edited by: cmdcenter on 12/15/2011 - 09:20
TomiZet
I hope I have the answer...

I hope I have the answer... After some search I found out 0x30 was used for MAPv1 (I think this corresponds to GSM Phase1) - you can verify via this [url=http://cgit.osmocom.org/cgit/asn1_docextract/tree/output/3.10.0/MAP-Oper......
CancelLocationArg ::= SEQUENCE {
imsi IMSI,
seq SEQUENCE{
imsi IMSI,
lMsId LMsId}}

This verification is possible because [url=http://laforge.gnumonks.org/weblog/2011/04/12/]this guy[/url] dug out MAPv1 asn definitions from the old MS-Word docs - wow!!

As of Phase2 the implicit sequence 0xA3 is used...
CancelLocationArg ::= [3] SEQUENCE {
identity Identity,
cancellationType CancellationType OPTIONAL,
extensionContainer ExtensionContainer OPTIONAL,
...}

So it should be like this: if there is no ACN present in TC-BEGIN carrying TC-INVOKE for cancelLocation operation(MAPv=1) - 0x30 shall be used. If there is ACN present (MAPv>1) - 0xA3 shall be used..

cmdcenter
Missing Sequence Tag

Thank you for your response TomiZet :)

Two questions though:

1- I have seen some packets where ACN is present but 0x30 has been used. (It might have been MAPv1, but it contained ACN)
2- I have seen some packets where neither 0x30 nor 0xA3 have been used. Is sequence tag optional in any case?

Any explanation?

TomiZet
I think this confusion comes

I think this confusion comes from MAPv2, where the arguments are encoded as CHOICE.. So this is what we know about CancelLocationArg (you can download corresponding TS from 3gpp.org):

Up to Ph1, 09.02 v 3.11.0 (corresponds to the end of MAPv1):

CancelLocationArg ::= SEQUENCE {
[list]
[*]imsi IMSI,
[*]seq SEQUENCE{
[*]imsi IMSI,
[*]lMsId LMsId}}
[/list]

Up to R96, 09.02 v 5.19.0 (corresponds to the end of MAPv2):
CancelLocationArg ::= CHOICE {
[list]
[*]imsi IMSI,
[*]imsi-WithLMSI IMSI-WithLMSI}
[/list]

Up to R97, 09.02 v 6.14.0 (corresponds to the beggining of MAPv3)
CancelLocationArg ::= [3] SEQUENCE {
[list]
[*]identity Identity,
[*]cancellationType CancellationType OPTIONAL,
[*]extensionContainer ExtensionContainer OPTIONAL,
[*]...}
[/list]

Remember there should be no ambiguity in the messages decoding because HLR never knows which VLR/SGSN will receive the message. So summary is:
With MAPv1 you have no ACN and always 0x30
With MAPv2 when you are encoding parameter for the invoke you can have:
[list]
[*]single IMSI, i.e tag for OCTET STRING -> this is case of ACN and no 0x30 nor 0xA3
[*]or IMSI-WithLMSI, i.e tags for the SEQUENCE of 2 OCTET STRINGs -> this is case of ACN and 0x30
[/list]
With MAPv3 you have always ACN and 0xA3

cmdcenter
Nice answer! Things are

Nice answer! Things are making sense now :)

There are still a few questions on my mind:

1- What's the main difference between these two series of specifications:

http://www.3gpp.org/ftp/Specs/html-info/0902.htm
http://www.3gpp.org/ftp/Specs/html-info/29002.htm

2- Do Ph1 and Ph2 exactly correspond to MAPv1 and MAPv2?

3- How can I know each document corresponds to which version of MAP? (like the way you have referred to them)

4- I didn't get what you mean by "[i]HLR never knows which VLR/SGSN will receive the message[/i]". Before encoding and sending a CancelLocation command to a VLR, how can I know which version of MAP should I choose to use?

5- Is [b]Sequence Tag[/b] always mandatory? Can it be omitted if say all parameters are optional and only one of them is present?

Thanks again :)

TomiZet
About 1) at the begining

About 1)
at the begining GSM(2G) was solely standardized by ETSI. But later - I think with the start of 3G - ETSI joined 3GPP. So currently you have two numbering schemes 09.02(good old ETSI numbering, applies for GSM only), 29.002(3GPP numbering apllies for 3G and beyond)

About 2) and 3)
seems I was mistaken - the version 5.19.0 was the standard which contained CHOICE definition for CancelLocationArg and the version 6.14.0 contained implicit SEQUENCE. I misinterpreted this as the end of MAPv2. But when I checked ACN definitions in the standard's history I noticed that:
The first ACNv2 strated to be used as of the 1st Ph2 09.02 version(). So Ph1 corresponds to MAPv1 where no ACNs are used. Then the 1st ACNv3 appeared in the 09.02 drafts for the R96. The 1st official standard for MAPv3 seems to be 09.02 v 5.5.2. So actually it is hard to say where does MAPv2 ends and MAPv3 begins - nowadays all implementations shall be MAPv3 and shall be backward compatible with the latest standard versions for MAPv1(v 3.11.0) and MAPv2(v 5.5.2 ?? - if you want to be 100% sure you need to verify with some MAP expert...).

About 4) by this I meant that presence/absence of ACN must unambigously identify how the MAP message is decoded. The point is VLR and HLR can be provided by different vendords so the MAP interface compatibility must be guaranteed. 09.02/29.002 defines a mechanism how the ACN version shall be maintained. In 29.002 there is dedicated chapter to this "Strategy for selecting the Application Context (AC) version" - anything else is vendor specific.