You are here

Camel_ MAP Version 1 and 2

7 posts / 0 new
Last post
gaedie_t
Camel_ MAP Version 1 and 2

Hi all
what is the difference betwen MAP version 1 and 2 as am experiencing MOC and MTC failure which i think this protocols might have effect on this. thanks

TomiZet
MAPv1 vs MAPv2

AFAIK the main difference is that MAPv1 does not make use of Application Context in the Dialogue portion. Use of Application Context is mandatory as of MAPv2. Also newer MAP version might introduce new MAP service or new parameters to the standing MAP services.

gaedie_t
Hi TomiZet Thanks alot, would

Hi TomiZet

Thanks alot, would the be errors in the dialogue if one of the two roaming operators implemented MAPv1 and the other MAPv2.

TomiZet
MAPversion downgrade

if entity supporting MAPv2 initiates dialogue with entity supporting only MAPv1 then the entity supporting only MAPv1 shall abort dialogue with the cause 'ACN not supported'. This should make the other entity to start new dialogue and to downgrade MAP version to v1

sama
Hi All, As I was reading

Hi All,

As I was reading through the TS29.002 for MAP, I came across a mapping between "AC Name & Version" and the
"Object Identifier:"

Example:-
-- AC Name & Version Object Identifier
-- networkLocUpContext-v2 map-ac networkLocUp (1) version2 (2)

Now, what happens with HLR sending a "Location Update" message with the AC Version as "v3" instead of "v2"

Will the "Location Update" procedure fails?
Will it generate some MAP error in return message from the MSC? OR
Will it generate some TCAP errors as 'AC not supported'?

I am just curious to know about the behavior if anyone has tested it in their network?

BR//
sama

gaedie_t
Hi all @Tomizet, thaks a lot

Hi all
@Tomizet, thaks a lot with that infor

@Sama i wish i can help, pity is am sill new in this industry. thanks

TomiZet
version downgrade applies

Hi Sama,

the approach to downgrade MAP version is generic to guarantee backward compatibility. If you check 29.002 you will find some chapter "Version handling at dialogue establishment". There is stated:

If version n is selected (where 1 < n <= highest existing version) and a MAP-OPEN Confirm primitive is received in response to the MAP-OPEN request with a result parameter set to "refused" and a diagnostic parameter indicating "application context not supported" or "potential version incompatibility problem", the MAP-User issues a new MAPOPEN request primitive with the equivalent version y context (where 1 <= y < n).

This is the same thing I described in the former post about downgrade from MAPv2 to MAPv1. So the third choice shall apply.