0% found this document useful (0 votes)
67 views

Map Version

MAP-APPLICATION CONTEXT

Uploaded by

gbollyp
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
67 views

Map Version

MAP-APPLICATION CONTEXT

Uploaded by

gbollyp
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 36

A900/1800 NSS - PLMN setting in RCP and HLR

3 MAP versions

3.1
© Alcatel University - 8AS 90200 0723 VT ZZA Ed.01

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.1


3 MAP versions
Session presentation

▼ Objective: Solve dialogue opening problems due


to MAP versions not supported by the HPLM
network elements.

3.2

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.2


MAP versions
Session presentation

▼ Program:
z 3 MAP versions
Î 3.1 Introduction
Î 3.2 Application context
Î 3.3 RCP programmable data
Î 3.4 HLR programmable data
Î 3.5 Appendix

3.3

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.3


3 MAP Versions

3.1 Introduction

3.4
© Alcatel University - 8AS 90200 0723 VT ZZA Ed.01

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.4


3.1 Introduction

▼ The object of MAP version management is to enable the GSM


networks and/or entities of a particular PLMN using different
MAP protocol versions to coexist.

z GSM phase 2+ introduces new services (CAMEL) and


procedural changes that have made it necessary to make
significant changes to the MAP protocol. These changes
are reflected in the definition of version 3 of the MAP
protocol (or MAP V3).

z From version 2, the MAP protocol is based on the White


Book TCAP protocol, which provides for an exchange of
information concerning dialogue management and dialogue
version negotiation.
3.5

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.5


3 MAP Versions

3.2 Application context

3.6
© Alcatel University - 8AS 90200 0723 VT ZZA Ed.01

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.6


3.2 Application context
Principle

▼ For compatibility, a network element that supports one MAP


version, or a part of that version, must also support previous
versions.
z The dialogue version is determined when dialogue is
opened, with the exchange of the first two messages
between the elements concerned.
z The version negotiation mechanism is based on the concept
of Application Context (AC), which is the reference for all the
operations that can be used during the dialogue.

▼ ACs and their MAP release values (V1, V2, V3) supported by
the local entity, both sending and receiving, are system
data.

3.7

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.7


3.2 Application context
AC negotiation : Opening dialogue with a remote entity

RCF or VLR or HLR


Remote entity Presentation VH Any function

What AC's version to be used with remote element?

Use Vn

Open dialogue towards remote element


TC – BEGIN White Book

TC – CONT / TC - END

AC returned accepted?

AC accepted

Components decoded

Sending Mode VH = version handler

3.8

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.8


3.2 Application context
AC : dialogue refused with a remote entity

RCF or VLR or HLR


Remote entity Presentation VH Any function

TC – BEGIN White Book

Which version?
Version not accepted
(Operator decision)
or
Version not supported
or
AC unknown
Use version n
TC – U - ABORT : reason=Acn not supported

TC – BEGIN version n

Receiving Mode VH = version handler

3.9

Unsolicited messages:

PMLX/1011 - HLM/1027: MAP version unknown in data for a PLMN entity


PMLX/1014 - HLM/1029: An entity of the PLMN has rejected a mandatory application context.

Note: See “ spontaneous messages dictionary RCP ”


3BL33098CBAAADJDA

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.9


3.2 Application context
Application context tables
▼ Data concerning the local entity,
z T-ENTINIT : Highest version allowed sending
z T-ENTMIN : Minimum version supported (no reversal possible with a version lower than that indicated in
this table).
▼ Data concerning the entities of the PLMN,
z T-ENTITY : indicates, for each remote entity of the HPLMN and for each AC, the MAP version to use for
transmission to the remote entity. (managed dynamically)
Î When the RCP or the HLR has to open a dialogue with an entity of the HPLMN that is not
included in the T_ENTITY table, a new entry is created in that table. The version of each AC for
this new remote machine is initialised using values from the T-ENTINIT table.
Î It is possible for AC values lower than the maximum T-ENTINIT values then to be registered for
a particular remote machine for fallback reasons.
Î However, a periodic update mechanism based on the initial T-ENTINIT values is use to test the
remote entities at regular intervals and, in this way, make sure that at all times the maximum
values allowed in reception are being used by the remote entities.

Î T-ENTITY is also updated following a cold restart. It is stored in RAM and backed up on the
standby subsystem.

▼ Data concerning the entities of the other PLMNs (see Roaming module).

3.10

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.10


3.2 Application context
Dynamic management of table T_ENTITY

N
Entity in the PLMN

Y See data
Search for concerning
access key entities of other
PLMNs

N There is no entry for this


Entity included in T_ENTITY
entity
Y
N
Version correct?
Add a record in T-ENTITY
Y
Output message N Set each AC with the highest
Version = 0? version allowed for sending
PMLX/1011
HLM1/1027 Y (T-ENTINIT)
AC not supported
→ end of
process
Take version
given by T- Take this version
ENTMIN

3.11

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.11


3.2 Application context
Dynamic management of table T_ENTITY
B

OK
Response to opening dialogue

NOK
Nothing to do

Version incompatible

Other version
Same version
supplied in ABORT No version supplied
supplied (White Book)
(White Book)

Remote end does not


accept AC name

T-ENTITY UPDATED
with this version T_ENTITY updated with
AC not supported → T_ENTMIN
T-ENTITY UPD. with
version 0

3.12

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.12


3.2 Application context
Management in sending mode

▼ When an entity (for example, RCP) needs to open a MAP dialogue in


sending mode to a remote machine, it has one of the following three items
of information:
z MSISDN : In the context of a terminating call at the GMSC
z IMSI : In the context of a first location
z E.164 address of the remote entity : In the case of an SS operation
originating from a located mobile.

▼ Analysis of the information enables the RCP to distinguish whether the


remote entity belongs to the HPLMN or whether it belongs to another
PLMN.
z In the former case, the T_ENTITY table is read to identify the version
of the AC (Application Context) to be used on opening dialogue.
z In the latter case, the T_NETWORK table is read.

3.13

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.13


3.2 Application context
Management in sending mode
▼ The procedure for identifying whether a remote entity belongs to the HPLMN is based on the use
of mechanisms, the nature of which depends on the information available :
z MSISDN
Î The RCP compares the CC of the MSISDN with PG-CC-V.
9 If the CC does not match PG-CC-V, then the MSISDN ∈ FPLMN, otherwise
the RCP analyses the NDC :
– The RCP compares the NDC of the MSISDN with the prefixes in list
D_NDC_CL. If there is a strict match with one of these prefixes, then
the entity ∈ HPLMN.
z IMSI
Î The MCC and MNC of the IMSI information are compared with the PB_MCC and
PB_MNC values : if there is a match, then the remote entity belongs to the HPLMN.
z E.164 address of the remote entity
Î The RCP compares the CC of the remote entity's E.164 address with the PG-CC-V.
9 If the CCs do not match, the RCP deduces that the remote entity ∈ FPLMN ,
otherwise the RCP analyses the NDC :
– NDC digits are compared with the prefixes in table D_NDC. If one of the
list strictly matches then the remote entity ∈ HPLMN

3.14

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.14


3.2 Application context
Management in sending mode

MSISDN CC=PG_CC_V ? N N MCC =


IMSI
E.164 address CC = HLS_CC ? PB_MCC ?
Y Y
NDC ∈ PG_NDC_CL_xyz ?
MNC =
NDC ∈ PG_NDC_xyz ? FPLMN
PB_MNC ?
NDC ∈ HLS_NDC N N
Y
READ
Y
T-NETWORK
HPLMN HPLMN

READ
TABLE T-ENTITY

AC 1 AC 2 AC n

E.164 or E.212 GT V2 V3 V1

E.164 GT V2 NSUP V1

3.15

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.15


3.2 Application context
Management in receiving mode

▼ On receipt of an MAP message from a remote machine of the HPLMN,


the RCP and the HLR must look up a table which provides the highest
MAP version allowed, when receiving, for the AC concerned. The table is
designated :
z D_ACCEPT for the RCP and
z HY_ACMAX for the HLR.

▼ Interchanges with entities belonging to FPLMNs are conducted after


looking up a table named T_NETWORK (see Roaming module).
z This table is used in sending and receiving modes.
z It supplies the MAP versions for the ACs, for each FPLMN. Table
T_NETWORK can be modified by MODNET.

▼ The management of receiving AC version is under F-VH-001

3.16

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.16


3.2 Application context
Management in receiving mode

Receipt of F-VH-001 Y
MAP message active?
N Receipt of GT from
N sending entity?
Y

Read table D-ACCEPT (RCP) or GTMCC=Home MCC ?


HY-ACMAX (HLR) which gives
the highest MAP Version (per GTMNC=Home MNC ?
AC) accepted by the receiving Y GTCC=Home CC ?
machine, regardless of sending
PLMNs. GTNDC ∈ List Home NDC ?
N

Read table T-NETWORK which indicates


the highest MAP version accepted by the
receiving machine
(for a given AC and for each PLMN).
Command : MODNET

3.17

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.17


3 MAP Versions

3.3 RCP programmable data

3.18
© Alcatel University - 8AS 90200 0723 VT ZZA Ed.01

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.18


3.3 RCP programmable data
NDC

Contains a list of NDCs used by the RCP to ascertain whether, on


D_NDC : opening an MAP dialogue (sending or receiving), the E.164 address of
the remote entity belongs to the HPLMN.
Sys. Par.: PARNAME = PG_NDC_051, NUM = DIGITS, RTDMS
Database: RELNAME = PYR_SYSG, ATR = D_NDC
List of fields:
D_NDC is a list made up of up to 32 NDCs.
Each prefix can be modified by the PG_NDC_xy1 parameter.
in which, xy = 1 to 32
Field values:
Each PG_NDC_xy1 parameter contains the NDC prefix digits that can
be compared with the E.164 address to work out whether the entity to
be reached belongs to the HPLMN.

3.19

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.19


3.3 RCP programmable data
NDC

Contains a list of MSISDN address NDCs. This list is used by the RCP
D_NDC_CL : to ascertain, when opening an MAP dialogue in sending mode, the
NDC of the called MSISDN belongs to the HPLMN.
Sys. Par.: PARNAME = PG_NDC_CL_301, NUM = NUM, RTDMS
Database: RELNAME = PYR_SYSG, ATR = D_NDC_CL
List of fields:
D_NDC_CL is a list made up of a maximum of 32 NDCs.
Each prefix can be modified by the PG_NDC_CL_xy1 parameter.
in which, xy = 01 to 32
Field values:
Each PG_NDC_CL_xy1 parameter contains the NDC prefix digits that
can be compared with the MSISDNs to work out whether the entity to
be reached belongs to the HPLMN.

3.20

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.20


3.3 RCP programmable data
T_ENTITY_initialisation period

Designates the period, expressed in days, between two initialisations


ENTI_RINIT_PER : of table T_ENTITY with table T-ENTINIT(D-ENTINI).
Sys. Par.: PARNAME = ENTI_RINIT_PER, NUM = NUM, RTDMS
Database: RELNAME = PYR_SYSG, ATR = D_VH_DAY
Example = D'01/ H'01

Tip: The value must be less than 6 days.


For more information, refer to the MAP version management FEX,
RXGMAP.

ENTI_RINIT_TIM : Defines the time at which T_ENTITY will be reset with the values from
T-ENTINIT(D-ENTINI).
Sys. Par.: PARNAME = ENTI_RINIT_TIM, NUM = NUM, RTDMS
Database: RELNAME = PYR_SYSG, ATR = D_VH_UPD
T_ENTITY is reset at time intervals defined as a number of days by
ENTI-RINIT-PER and at the time of the day defined by
ENTI-RINIT-TIM.
Example = D'23/ H'17

3.21

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.21


3.3 RCP programmable data
T_ENTITY_initialisation period

Contains the delay expressed in hours between restarting the RCP


PG_VH_MIN :
(RCP Reset) and the first update of T_ENTITY by T-ENTINIT (D-
ENTIN).
Sys. Par.: PARNAME = PG_VH_MIN, NUM = NUM, RTDMS
Database: RELNAME = PYR_SYSG, ATR = D_VH_MIN

Tip: The PG_VH_MIN value must be less than 12 hours.


Example = D'4/ H'04

3.22

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.22


3.3 RCP programmable data
AC version management

Caution: To complete D_ENTINI, you must know the capabilities of the RCP machine for
handling ACs in sending mode.

T_ENTINIT Table containing the highest values allowed by the operator for ACs outgoing to the
(D_ENTINI) : entities of the HPLMN. It is used periodically to reset the dynamic table T_ENTITY.

Sys. Par.: PARNAME = OG_R_VERS_LOCUPD, NUM = VERS, RTDMS Database:


RELNAME = PYR_SYSG, ATR = D_ENTINI
The parameters used to modify this table, and the associated ACs, are:
OG_R_VERS_LOCUPD : Network Location Update AC
OG_R_VERS_LOCRET : Location Info Retrieval AC
OG_R_VERS_HANDOV : Handover Control AC
OG_R_VERS_NWFSSH : Network Functional SS AC
OG_R_VERS_NWUSSH : Network Unstructured SS AC
OG_R_VERS_MSPURG : Mobile Station Purging AC
OG_R_VERS_SMMORL : Mobile Originating Short Message Relay AC
OG_R_VERS_SMWDTM : Short Message Waiting Data Management AC
OG_R_VERS_EQPMNG : Equipment Management AC
OG_R_VERS_INFRET : Information retrieval AC
OG_R_VERS_VLRRET : Inter VLR information retrieval AC
OG_R_VERS_SMGWAY : Short Message Gateway AC
OG_R_VERS_SMTCRL : Mobile Terminating Short Message Relay AC
OG_R_VERS_REPORT : Reporting AC
OG_R_VERS_CCOMP : Call Completion AC
OG_R_VERS_CCOTRA : Call Control Transfer AC
OG_R_VERS_SSNOTI : SS-Invocation Notification AC
3.23

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.23


3.3 RCP programmable data
AC version management

Contains the highest AC versions allowed by the RCP machine in receiving


D_ACCEPT :
mode.
This table is used in all intra-PLMN incoming dialogues. It is also used for
inter-PLMN incoming dialogues if F-VH-001 is set to FAUX (FALSE).
Sys. Par.: PARNAME = IC_R_VERS_LOCCAN, NUM = VERS, RTDMS
Database: RELNAME = PYR_SYSG, ATR = D_ACCEPT
The parameter names and their application contexts are:
IC_R_VERS_LOCCAN : Location Cancellation AC
IC_R_VERS_RNBENQ : Roaming Number Enquiry AC
IC_R_VERS_HLRRST : Reset AC
IC_R_VERS_HANDOV : Handover Control AC
IC_R_VERS_INFRET : Information retrieval AC
IC_R_VERS_VLRRET : Inter VLR information retrieval AC
IC_R_VERS_SUBDTM : Subscriber Data Management AC
IC_R_VERS_TRCING : Tracing AC
IC_R_VERS_NWUSSH : Network Unstructured SS AC
IC_R_VERS_SMMORL : Mobile Originating Short Message Relay AC
IC_R_VERS_SMTCRL : Mobile Terminating Short Message Relay AC
IC_R_VERS_SMALRT : Short Message Alert AC
IC_R_VERS_SINENQ : Subscriber information enquiry AC
IC_R_VERS_REPORT : Reporting AC

3.24

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.24


3.3 RCP programmable data
AC version management

Defines which of the two tables, D-ACCEPT or T_NETWORK, contains the list
F-VH-001 : of the highest AC versions accepted by the RCP on opening an incoming
dialogue originating from a machine from a PLMN other than the HPLMN.
Sys. Par.: PARNAME = PB_F_VH_001, NUM = BOOL, RTDMS Database:
RELNAME = PYR_SYSB, ATR = D_VH_001
Field values:
VRAI (TRUE): T_NETWORK contains not just the AC versions used in sending
mode, but also the highest AC versions allowed in receiving mode for each
foreign PLMN.
In the case of a sending PLMN that is not the HPLMN, T_NETWORK is
scanned to ascertain the highest version allowed for this AC. If F-VH-001 is
set to VRAI (TRUE), the RVERSION and RAPCTX parameters can be used by
the MODNET command and AC version management dependent on the
sending PLMN is authorised.
FAUX (FALSE): The AC versions allowed in receiving mode are described in
table D-ACCEPT and not in T_NETWORK. The declaration of the highest
versions accepted in receiving mode is independent of the originating PLMN.

3.25

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.25


3 MAP Versions

3.4 HLR programmable data

3.26
© Alcatel University - 8AS 90200 0723 VT ZZA Ed.01

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.26


3.4 HLR programmable data
T_ENTITY_initialisation period

ENTI_RINIT_PER : Designates the period, expressed in days, between two initialisations


of table T_ENTITY by table T-ENTINIT (HY-ENTIN).

Sys. Par.: PARNAME = ENTI_RINIT_PER, NUM = NUM, RTDMS


Database: RELNAME = HYR_HLS, ATR = HY_VH_DA
Relevant process: Same principle as for the RCP.
If ENTI_RINIT_PER is set to zero, the initialisation period is 24 hours.
Example = D'30/ H'1E - Day

Defines the time at which T_ENTITY is reinitialised with values from T-


ENTI_RINIT_TIM :
ENTINIT (HY-ENTIN).
T_ENTITY is reset at time intervals defined as a number of days by
ENTI_RINIT_PER and at the time of day defined by ENTI_RINIT_TIM.
Sys. Par.: PARNAME = ENTI_RINIT_TIM, NUM = NUM, RTDMS
Database: RELNAME = HYR_HLS, ATR = HY_VH_UP
Example = D'3/ H'03 - Time

3.27

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.27


3.4 HLR programmable data
T_ENTITY_initialisation period

C ontains the delay in hours between restarting the H LR (H LR Reset)


H LS_VH_MI :
and the first update of T_EN TITY by T-ENTINIT (HY_ENTIN).
Sys. Par.: PARNAME = HLS_VH_MI, NUM = NUM, RTDMS Database: RELNAME
= HYR_HLS, ATR = HY_VH_MI

For m ore information refer to the MAP version management FEX,


R XGM AP.
Exam ple = D'36/ H '24 C LOCK

3.28

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.28


3.4 HLR programmable data
AC version management
Caution: To complete HY-ACMAX, you must know the capabilities of the HLR
machine for handling ACs in receiving mode.
Contains the highest AC (Application Context) versions allowed by the HLR
machine in receiving mode. This table is used in all intra-PLMN incoming
HY_ACMAX : dialogues. It is also used for inter-PLMN incoming dialogues if F-VH-001 is set
to FAUX (FALSE).
Sys. Par.: PARNAME = IC_H_VERS_LOCUPD, NUM = HEXA, RTDMS
Database: RELNAME = HYR_HLS, ATR = HY_ACMAX
The parameters in this table, and their associated ACs, are:
IC_H_VERS_LOCUPD : Network Location Update AC
IC_H_VERS_LOCRET : Location Information Retrieval AC
IC_H_VERS_INFRET : Information Retrieval AC
IC_H_VERS_NWFSSW : Network Functional SS AC
IC_H_VERS_SMGWAY : Short Message gateway AC
IC_H_VERS_SMWDTM : Short Message Waiting Data Management AC
IC_H_VERS_MSPURG : MS Purging AC
IC_H_VERS_IMSIRT : IMSI Retrieval AC
IC_H_VERS_ATIENQ : Any Time Interrogation Enquiry AC
IC_H_VERS_REPORT : Reporting AC
IC_H_VERS_CCOMP : CallCompletion AC
IC_H_VERS_GPLCUP : GPRS Location Update AC
IC_H_VERS_NWUSSH : Network unstructured SS AC
3.29

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.29


3.4 HLR programmable data
AC version management
Caution: To complete HY-ENTIN, you must know the capabilities of the HLR machine for
handling ACs in sending mode.

T_ENTINIT Table containing the highest values allowed by the operator for ACs
(HY_ENTIN) : outgoing to entities of the HPLMN. It is used periodically to reset the
dynamic table T_ENTITY.
Sys. Par.: PARNAME = OG_R_VERS_LOCUPD, NUM = VERS, RTDMS
Database: RELNAME = HYR_HLS, ATR = HY_ENTIN
The parameters of this table and their associated application contexts are:
OG_H_VERS_LOCCAN : Location Cancellation AC
OG_H_VERS_RNBENQ : Roaming Number Enquiry AC
OG_H_VERS_HLRRST : Reset AC
OG_H_VERS_SUBDTM : Subscriber data Management AC
OG_H_VERS_TRCING : Tracing AC
OG_H_VERS_NWUSSH : Network Unstructured SS AC
OG_H_VERS_SMALRT : Short Message Alert AC
OG_H_VERS_SINENQ : Subscriber Information Enquiry AC
OG_H_VERS_REPORT : Reporting AC
OG_H_VERS_GPNOT : GPRS Notifying AC
3.30

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.30


3.4 HLR programmable data
AC version management

Used to manage, for each PLMN in turn, the highest AC versions accepted for
F-VH-001 :
incoming dialogues.
Sys. Par.: PARNAME = HLS_F_VH_001, NUM = BOOL, RTDMS Database:
RELNAME = HYR_HLS, ATR= HY_U_HLR
Relevant process:
F-VH-001 defines which of the two tables, HY-ACMAX (T_ACCEPT for the RCP)
or T_NETWORK, contains the list of the highest AC versions accepted by the HLR
on opening an incoming dialogue originating from a machine from a PLMN other
than the HPLMN.
Note: T_NETWORK can be modified by the MODNET command while HY-
ACMAX can be modified by the MODSYH command.
Field values:
VRAI (TRUE): T_NETWORK contains, in addition to the AC versions used in
sending mode, the highest AC versions allowed in receiving mode for each foreign
PLMN.
The choice of whether to read table T_NETWORK or HY-ACMAX dependent on
the nature (HPLMN or other) of the remote entity.
FAUX (FALSE): The AC versions allowed in receiving mode are described in table
HY_ACMAX and not T_NETWORK.

3.31

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.31


3.4 HLR programmable data
AC version management
▼ The nature (HPLMN or other) of the remote entity is based on the presence of
SCCP GT of the remote entity included in the received frame :
z If absent, then the AC version is read from HY_ACMAX (INTRA-PLMN
remote entity).
z If present, then the HLR application's translator (ORIG=ENTTRA) is
called to analyse the address :
Î The MCC and MNC parameters returned by the final translation
result are compared respectively with HLS_MCC and HLS_MNC.
' If at least one of the parameters differs from HLS_MCC or
HLS_MNC, then the remote entity is considered not to belong
to the HPLMN and T_NETWORK is addressed.
' If both MCC and MNC parameters match HLS_MCC and
HLS_MNC, then the remote entity is considered to belong to
the HPLMN and HY_ACMAX is read.

3.32

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.32


3 MAP Versions

3.5 Appendix

3.33
© Alcatel University - 8AS 90200 0723 VT ZZA Ed.01

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.33


3.5 Appendix 1
AC and versions supported in R7
Application Context Versions supported

RCP HLR
GSM standard name Mnemonic
Sending Receiving Sending Receiving

NetworkLocUp LOCUDP V1, V2, V3 - - V1, V2, V3

LocationCancellation LOCCAN - V1, V2, V3 V1, V2, V3 -

RoamingNumberEnquiry RNBENQ - V1, V2, V3 V1, V2, V3 -

LocationInfoRetrieval LOCRET V1, V2, V3 - - V1, V2, V3

Reset HLRRST - V1, V2 V1, V2 -

HandoverControl HANDOV V1, V2, V3 V1, V2, V3 - -

EquipmentMngt EQMNGT V1, V2 - - -

InfoRetrieval INFRET V1, V2,V3 V1 - V1, V2, V3

InterVlrInfoRetrieval VLRRET NSUP V2, V3 - -

SubscriberDataMngt SUBDTM - V1, V2, V3 V1, V2, V3 -

Tracing TRCING - V2, V3 V2, V3 -

NetworkFunctionalSs NWFSSH V1, V2 - - V1, V2

NetworkUnstructuredSs NWUSSH V2 V2 V2 V2

Authentication Failure AUFAIL V3 - - V3


3.34

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.34


3.5 Appendix 1
AC and versions supported in R7

Application Context Versions supported

RCP HLR
GSM standard name Mnemonic
Sending Receiving Sending Receiving

shortMsgGateway SMGWAY V1, V2, V3 - - V1, V2, V3

ShortMsgRelay
SMMORL V1, V2, V3 V1, V2, V3 - -
shortMsgMO-Relay

ShortMsgMT-Relay SMTCRL V2, V3 V2, V3 - -

shortMsgAlert SMALRT - V1, V2 V1, V2 -

MwdMngt SMWDTM V1, V2 - - V1, V2, V3

MsPurging MSPURG V2, V3 - - V2, V3

ImsiRetrieval IMSIRT NSUP - - V2

SubscriberInformationEnquiry SINENQ - V3 V3 -

AnyTimeInterrogationEnquiry ATIENQ - - - V3

Reporting REPORT V3 V3 V3 V3

CallCompletion CCOMP V3 - - V3

CallControlTransfer CCOTRA V3 V3 - -

GprsLocationUpdate GPLCUP - - - V3

ss-InvocationNotification SSNOTI V3 - - -

3.35

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.35


3 MAP version
Evaluation

▼ Objective: to be able to solve opening


problems due to MAP versions not
supported by the HPLMN network
element

Thank you for answering


the self-assessment
of the objectives sheet

3.36

© Alcatel University - 8AS 90200 0723 VH ZZA Ed.01 Page 3.36

You might also like