NP-020358

7/29/2019 NP-020358

1/49

3GPP TSG CN Plenary Meeting #17 NP-0203584

th- 6

thSeptember 2002. Biarritz, France.

Title: LS on Shared Networks

Release: Release 5

Source: CN4Agenda item: 5.1

Document for: INFORMATION

3GPP TSG CN WG4 Meeting #15 N4-021098Helsinki, Finland, 29

th July 2nd

August 2002

Title: LS on Shared Networks

Response to: LS R3-021795 (N4-020818) on Shared Networks from RAN3.LS R3-021816 (N4-020865) on Shared Networks Outcome of RAN3#30 from

RAN3.LS S2-022054 (N4-020872) on Shared Networks from SA2

Release: Release 5

Source: CN4

To: RAN3, SA2, GERAN, GERAN2

Cc: CN

Contact Person:Name: Pompeo SantoroTel. Number: +39 081 5147721E-mail Address: [email protected]

1. Overall Description:

TSG CN4 would like to thank RAN3 and SA2 for their LSs R3-021795, R3-021816 and S2-022054 on SharedNetworks.

In response to the action for CN4 outlined in LS R3-021795, CN4 would like to confirm that the RAN3assumption:

The understanding in TSG RAN WG3 is that the underlying assumption in TSG CNWG4 is that all the Subscriber Access Information (for instance, to which SNA theSubscriber is allowed to access) is located in the Anchor MSC and, during aHandover in CS Domain involving 2 MSCs, it is passed over to the Non-AnchorMSC over the E-interface

is indeed correct.

In response to the action for CN4 outlined in LS S2-022054 and LS R3-021816 asking for modifications of therelevant TSs, CN4 could unfortunately not agree on a single solution to transport the SNA Access Informationfrom anchor MSC to non anchor MSC for an inter-MSC Handover.

The discussion point has been whether the SNA Access Information should be transferred from anchor MSC tonon anchor MSC as MAP parameter of the MAP operation Prepare Handover, or as a BSSMAP parameter tobe carried in the BSSMAP Handover Request message encapsulated in the MAP operation Prepare Handoverfor the Inter MSC GSM to GSM, UMTS to GSM and GSM to UMTS Handover.

7/29/2019 NP-020358

2/49

The majority view expressed at CN4 was that the transport at BSSMAP level is preferred, but this preferenceneeds to be confirmed by GERAN.

The first alternative solution, transport at MAP level, can be completed by modifications to only CN4specifications.

The second alternative solution, transport at BSSMAP level, requires modifications to CN4 specifications and tospecifications in the remit of GERAN.

However, in the wish to provide a solution in the required time frame, CN4 has agreed to produce two sets ofCRs to the relevant specifications.

The first set being all the necessary modifications needed if the transport of the SNA Access Information atMAP level is used. The set consists of a CR on 29.002 and one on 29.010.

The second set being all the necessary modifications needed on CN4 specifications if the transport of the SNAAccess Information at BSSMAP level is used. This second set of CRs depends on the approval at GERAN ofall the CRs necessary to GERAN specifications (e.g. 48.008). This set consists of only one CR on 29.010.

Moreover two additional CRs have been agreed, one of them together with CN1. Those CR s, on 23.003 and23.009, are equally applicable for both solutions.

In response to the action for CN4 outlined in LS S2-022054, CN4 would like to reassure SA2 that themodifications agreed for both solutions cater for the requirements on Shared Network in connected mode for allrelevant traffic cases including GSM to UMTS inter-MSC handover.

Its CN4 assessment that no further work is necessary on CN4 specifications.

NOTE: The agreed CRs are attached to this LS in three zip files. One for the CR s implementing thetransport at MAP level, one for the CR implementing the transport at BSSMAP level, one for the CRsindependent of the selected transport.

2. Actions:

To RAN3, SA2

ACTION: CN4 kindly asks RAN3 and SA2 to note CN4 reply to their LSs.

To GERAN, GERAN2

ACTION: CN4 kindly asks GERAN and GERAN2 to investigate on the feasibility and appropriateness oftransporting the SNA Access Information at BSSMAP level, and, if deemed so, to produce thenecessary CRs to the relevant specifications.

3. Date of Next CN4 Meetings:

CN4 #16 23rd

Sep.27th

Sep. 2002 Miami, USA

CN4 #17 11th

Nov.15th

Nov. 2002 Bangkok, Thailand

7/29/2019 NP-020358

3/49

CR page 1

3GPP TSG CN WG4 Meeting #15 N4-021104Helsinki, Finland, 29th July 2nd August 2002

CR-Form-v7

CHANGE REQUEST

= 29.010 CR 075 = rev - = Current version: 5.0.0 =

ForHELPon using this form, see bottom of this page or look at the pop-up text over the = symbols.

Proposed change affects: UICC apps = ME Radio Access Network Core Network X

Title: = Support for Shared Network in connected mode (using encapsulated BSSAPtransport of SNA access information)

Source: = Nokia

Work item code:= TEI5 Date:= 01/08/2002

Category: = B Release:= REL-5Use one of the following categories:

F (correction)

A (corresponds to a correction in an earlier release)B (addition of feature),C (functional modification of feature)

D (editorial modification)Detailed explanations of the above categories canbe found in 3GPP TR 21.900.

Use one of the following releases:2 (GSM Phase 2)R96 (Release 1996)R97 (Release 1997)R98 (Release 1998)R99 (Release 1999)Rel-4 (Release 4)Rel-5 (Release 5)

Rel-6 (Release 6)

Reason for change: = RAN#3 has agreed on a solution for the support of Shared Networks inconnected mode in Release 5. See TR R3:012 available in LS N4-020865 (R3-021816).

The agreed solution is based on the concept of SNA, which is basically acollection of Location Areas.

A set of allowed SNAs is associated to each IMSI serie.

The set of allowed SNAs, the SNA Access Information, is signalled to the RadioNetwork when a call is setup, so that the Radio Network can decide whether asubscriber can be handed over when moving to a new Location Area, i.e. if hehas authorization to get service in that Location Area.

During the Handover procedure the anchor MSC has to inform the non-anchorMSC about the SNA Access Information of the subscriber so that non-anchorMSC shall be able to forward this information to the Radio Network whenperforming subsequent intra-MSC handovers. The allowed SNAs are added toPrepareHandover.

Summary of change:= The list of allowed SNAs is added to MAP PrepareHandover.

Consequences if =not approved:

Support of Shared Network in connected mode would not be available after aninter-MSC Handover.

Clauses affected: =

7/29/2019 NP-020358

4/49

CR page 2

Y N

Other specs=

Y Other core specifications=

48.008 CR xxx23.003 CR 05023.009 CR xxx

affected: N Test specifications

N O&M Specifications

Other comments:=

How to create CRs using this form:Comprehensive information and tips about how to create CRs can be found at http://www.3gpp.org/specs/CR.htm.Below is a brief summary:

1) Fill out the above form. The symbols above marked=

contain pop-up help information about the field that they areclosest to.

2) Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word"revision marks" feature (also known as "track changes") when making the changes. All 3GPP specifications can bedownloaded from the 3GPP server under ftp://ftp.3gpp.org/specs/ For the latest version, look for the directory namewith the latest date e.g. 2001-03 contains the specifications resulting from the March 2001 TSG meetings.

3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front ofthe clause containing the first piece of changed text. Delete those parts of the specification which are not relevant tothe change request.

7/29/2019 NP-020358

5/49

3GPP TS aa.bbb vX.Y.Z (YYYY-MM) CR page 3

CR page 3

**** FIRST MODIFIED SECTION ****

4.5 Inter-MSC Handover

4.5.5 Processing in MSC-B, and information transfer on E-interface

The following parameters require processing (e.g. to store the parameter, to internally generate the parameter) in

MSC-B. The relevant BSSMAP procedures are mentioned to ease the comprehension, their detailed description is thescope of 3GPP TS 48.008. Each BSSMAP message listed in 3GPP TS 49.008 being transferred on E-interface shall use

the mechanisms given in subclause 4.5.4 and is described in 3GPP TS 48.008.

For intra-MSC-B handover/relocation and security interworking , after inter-MSC handover from GSM to GSM, the

3G_MSC-B needs additional information to be able to perform security mode and integrity protection procedures.

These RANAP informations are transferred between MSC-A and 3G-MSC-B in MAP messages, defined in 3GPP TS

29.002.

For subsequent handover/relocation, after inter-MSC handover from GSM to GSM, the 3G_MSC-B needs additional

information to be able to perform service handover procedures. The relevant information is transferred between MSC-A

and 3G-MSC-B in MAP messages, defined in 3GPP TS 29.002.


information to be able to forward access rights information in the context of Shared Network to the RAN. The relevant

information is transferred between MSC-A and 3G-MSC-B in MAP messages, defined in 3GPP TS 29.002.

**** NEXT ADDED SECTION ****

4.5.5.12 SNA Access Information

This information shall be stored by 3G_MSC-B and sent to an RNS in the Relocation Request message when 3G_MSC-

B performs handover to UMTS.

Transfer of information:

The SNA Access Information is transferred to 3G_MSC-B in:

the Handover Request BSSMAP message.

**** NEXT MODIFIED SECTION ****

4.7 Inter-MSC Handover (GSM to UMTS)

7/29/2019 NP-020358

6/49


CR page 4

4.7.1 Basic Inter-MSC Handover

When a Mobile Station is handed over between two MSCs, the establishment of a connection between them (described

in 3GPP TS 23.009) requires interworking between A-Interface, Iu-Interface and E-Interface.

The signalling at initiation, execution and completion of the Basic Inter-MSC handover procedure is shown in figures

37 to 42 with both possible positive or negative outcomes.

Additionally figure 37b shows the possible interworking when the trace related message is transparently transferred on

the E-Interface at Basic Inter-MSC Handover initiation.

BSS-A MSC-A 3G-MSC-B| | ||HANDOVER | ||-------------->|MAP PREPARE HANDOVER ||REQUIRED |------------------------>| +----------------+| |request | |Possible Alloc. || | | |of a handover || | | |no. in the VLR-B|| | | +----------------+| | || | | RNS-B

| | | || | |RELOCATION REQUEST || | |------------------>|

Figure 37a: Signalling for Basic Inter-MSC Handover initiation (no trace related messagestransferred)

BSS-A MSC-A 3G-MSC-B| (*) ||HANDOVER | ||-------------->|MAP PREPARE HANDOVER ||REQUIRED |------------------------>| +----------------+| |request (**) | |Possible Alloc. || | | |of a handover |

| | | |no. in the VLR-B|| | | +----------------+| | || | | RNS-B| | | || | |RELOCATION REQUEST || | |------------------>|| | | || | |CN INVOKE TRACE || | |--------------->(***)

Figure 37b: Signalling for Basic Inter-MSC Handover initiation (CN invoke trace message transferred)

(*): Tracing invocation has been received from VLR.

(**): In that case, HANDOVER REQUEST and MSC INVOKE TRACE messages are included within theAN-apdu parameter.

(***): CN INVOKE TRACE is forwarded to RNS-B if supported by 3G_MSC-B.

Possible Positive outcomes: successful radio resources allocation and handover number allocation (if performed):

7/29/2019 NP-020358

7/49


CR page 5

BSS-A MSC-A 3G-MSC-B RNS-B| | | || | |RELOCATION REQUEST || | ||| | |CONTROL || | MAP PREPARE HANDOVER | || |

7/29/2019 NP-020358

8/49


CR page 6

BSS-A MSC-A 3G-MSC-B RNS-B| | | || | |RELOCATION COMPLETE|| | || || | |IU RELEASE COMMAND || | |------------------>|| | | |

Figure 42: Signalling for Basic Inter-MSC Handover completion (Negative outcome)

NOTE 2: From interworking between MAP and RANAP point of view, when the call is released.

BSS-A MSC-A 3G-MSC-B RNS-B| | | || | |LOCATION REPORT || | |

7/29/2019 NP-020358

9/49


CR page 7

----------------------------------------------------------------| 408.008 29.002 |Notes

--------22Forward | HANDOVER REQUIRED MAP PREPARE HANDOVER request|message | |

| -ho-NumberNotRequired| 1| BSSMAP information -target RNC Id || elements -IMSI |

| -Integrity protection|2| info || -Encryption info || -an-APDU( | 3| HANDOVER REQUEST, || MSC INVOKE TRACE) | 4

--------22Positive| MAP PREPARE HANDOVER response|result | | 5

| -handover number || -an-APDU( || HANDOVER REQUEST || ACKNOWLEDGE or || HANDOVER FAILURE) |

--------22Negative| HANDOVER REQUIRED REJECT MAP PREPARE HANDOVER| 6result | |

| equipment failure System Failure || equipment failure No Handover Number || available || equipment failure UnexpectedDataValue|| equipment failure Data Missing || || equipment failure MAP CLOSE || equipment failure MAP U/P -ABORT || |

NOTE 1: The ho-NumberNotRequired parameter is included by MSC-A, when MSC-A decides not to use anycircuit connection with 3G_MSC-B. No handover number shall be present in the positive result. Any

negative response from 3G_MSC-B shall not be due to handover number allocation problem.

NOTE 2: Integrity protection information, encryption information and IMSI parameters are included by MSC-A,

only when the MSC-A uses 29.002 as per release 99. These IEs are not included if the MSC-A is R98 or

earlier.

NOTE 3: The process performed on the BSSMAP information elements received in the HANDOVER REQUIRED

message is described in the 3GPP TSGSM Recommendation 408.008.

NOTE 4: The process performed on the BSSMAP information elements received in the MSC INVOKE TRACE

message is described in subclause 4.5.5.6.

NOTE 5: The response to the Prepare-Handover request can include in its an-APDU parameter, identifying the

GSM 08.06 protocol, either a BSSMAP HANDOVER REQUEST ACKNOWLEDGE or a BSSMAP

HANDOVER FAILURE.

In the first case, the positive result triggers in MSC-A the sending on A-Interface of the HANDOVERCOMMAND.

In the second case, the positive result triggers in MSC-A optionally the sending of the HANDOVER

REQUIRED REJECT.

(The possible sending of the HANDOVER REQUIRED REJECT message upon receipt of the

HANDOVER FAILURE is out of the scope of 3GPP TS 29.010 and lies in 3GPP TS 48.008).

NOTE 6: The possible sending of the HANDOVER REQUIRED REJECT message is described in3GPP TS

48.008.

The interworking between Prepare Handover and RELOCATION REQUEST in 3G_MSC-B is as follows:

7/29/2019 NP-020358

10/49


CR page 8

----------------------------------------------------------------| 29.002 25.413 |Notes

--------22Forward | MAP PREPARE HANDOVER RELOCATION REQUEST |message | request |

| -ho-NumberNotRequired || -target RNC Id || -IMSI |

| -Integrity protection info |1| -Encryption info || -RANAP service handover || -an-APDU( || HANDOVER REQUEST, || MSC INVOKE TRACE) || || BSSMAP information RANAP information || elements: elements: || || Channel Type RAB parameters || Cause Cause || sRNC to tRNC container sRNC to tRNC container|| SNA Access Information SNA Access Information| 2| || info stored/generated || in/by 3G_MSC-B: || CN domain indicator || |

--------22Positive| MAP PREPARE HANDOVER RELOCATION REQUEST ACK |result | response |

| -an-APDU( || HANDOVER REQUEST ACK) || || BSSMAP information RANAP information || elements: elements: || || Layer 3 info tRNC to sRNC container|| |

--------22Negative| MAP PREPARE HANDOVER RELOCATION FAILURE |result | response |

| -an-APDU( || HANDOVER FAILURE) || |

NOTE 1: Integrity protection information, encryption information, IMSI and RANAP service handover parametersare included by MSC-A, only when the MSC-A uses 29.002 as per release 99. These IEs are not included

if the MSC-A is R98 or earlier.

NOTE 2: SNA Access Information parameter is included by MSC-A, only when the MSC-A uses 29.002 as per

release 5. These IEs are not included if the MSC-A is release 4 or earlier.

The interworking between Send End Signal and RELOCATION COMPLETE in 3G_MSC-B is as follows:

----------------------------------------------------------------| 25.413 29.002 |Notes

--------

2

2

Forward | RELOCATION COMPLETE MAP SEND END SIGNAL request |message | |

| -an-APDU( || HANDOVER COMPLETE)|| |

--------22Positive| IU RELEASE COMMAND MAP SEND END SIGNAL response|result | -Normal release | 1--------22Negative| IU RELEASE COMMAND |result | -Normal release MAP CLOSE | 2

| -Normal release MAP U/P -ABORT|| |

NOTE 1: The positive empty result triggers the clearing of the Radio Resources on the Iu-Interface and the release

of the SCCP connection between 3G_MSC-B and RNS-B. If a circuit connection is used between MSC-Aand 3G_MSC-B, the 'Normal release' clearing cause shall only be given to RNS-B when 3G_MSC-B has

received a clearing indication on its circuit connection with MSC-A.

7/29/2019 NP-020358

11/49


CR page 9

NOTE 2: The abortion of the dialogue or the rejection of the component triggers in 3G_MSC-B the clearing of its

circuit connection with MSC-A, if any, of the Radio Resources on the Iu-Interface and the release of the

SCCP connection between 3G_MSC-B and RNS-B.

The interworking between Send End Signal and CLEAR COMMAND in MSC-A is as follows:

----------------------------------------------------------------

| 29.002 08.08 |Notes--------22Forward | MAP SEND END SIGNAL CLEAR COMMAND |message | request |

| -an-APDU( - Handover || HANDOVER COMPLETE) Successful |

--------22Positive| |result | |--------22Negative| |result | |

The interworking between HANDOVER FAILURE in case of reversion to old channel of the MS and User Abort in

MSC-A is as follows:

----------------------------------------------------------------| 408.008 29.002 |Notes

--------22Forward | HANDOVER FAILURE MAP U -ABORT |message | |

| - Reversion to old || channel |



4.7.4 BSSAP Messages transfer on E-Interface

The handling is described in chapter 4.5.4, additional cases are described in this chapter.

4.7.4.1 Assignment

The interworking between the BSSMAP assignment messages in MAP and the RANAP RAB assignment messages is

as follows:

7/29/2019 NP-020358

12/49


CR page 10

----------------------------------------------------------------| 29.002 25.413 |Notes

--------22Forward | MAP PREPARE HANDOVER RAB ASSIGNMENT REQ|message | request |

| -RANAP service Service handover || handover || -an-APDU( |

| ASSIGNMENT REQUEST) || || BSSMAP information RANAP information || elements: elements: || || Channel Type RAB parameters || |

--------22Positive| MAP PREPARE HANDOVER |result | request |

| -an-APDU( || ASSIGNMENT COMPLETE RAB ASSIGNMENT || RESPONSE || or (positive result)|| ASSIGNMENT FAILURE) RAB ASSIGNMENT || RESPONSE || (negative result)|| || BSSMAP information RANAP information || elements: elements: || || Cause Cause |1| |

--------22Negative| |result | MAP U/P ABORT |

| |


4.7.5 Processing in 3G_MSC-B, and information transfer on E-interface






the Handover Request BSSMAP message.


4.8 Inter-MSC Relocation..

7/29/2019 NP-020358

13/49


CR page 11


..






the Relocation Request RANAP message encapsulated in the Prepare Handover request MAP message.

**** END OF MODIFICATIONS ****

7/29/2019 NP-020358

14/49

CR page 1


CR-Form-v7

CHANGE REQUEST

= 29.002 CR 466 = rev 1 = Current version: 5.2.0 =



Title: = Support for Shared Network in connected mode

Source: = Ericsson



F (correction)A (corresponds to a correction in an earlier release)B (addition of feature),C (functional modification of feature)


Use one of the following releases:2 (GSM Phase 2)R96 (Release 1996)R97 (Release 1997)R98 (Release 1998)R99 (Release 1999)Rel-4 (Release 4)Rel-5 (Release 5)Rel-6 (Release 6)





During the Handover procedure the anchor MSC has to inform the non-anchorMSC about the SNA Access Informationof the subscriber so that non-anchorMSC shall be able to forward this information to the Radio Network whenperforming subsequent intra-MSC handovers. The allowed SNAs are added toPrepareHandover.

.




Clauses affected: = 7.6, 7.6.6.4, 8.4.1.2, 8.4.1.3, 17.7.1

7/29/2019 NP-020358

15/49

CR page 2

Y N

Other specs=

X Other core specifications=

29.010 CR 05823.003 CR 05023.009 CR 080

affected: X Test specificationsX O&M Specifications

Other comments: =


1) Fill out the above form. The symbols above marked = contain pop-up help information about the field that they areclosest to.




7.6 Definition of parameters

Following is an alphabetic list of parameters used in the common MAP-services in clause 7.3:

Application context name 7.3.1 Refuse reason 7.3.1Destination address 7.3.1 Release method 7.3.2Destination reference 7.3.1 Responding address 7.3.1Diagnostic information 7.3.4 Result 7.3.1Originating address 7.3.1 Source 7.3.5Originating reference 7.3.1 Specific information 7.3.1/7.3.2/7.3.4Problem diagnostic 7.3.6 User reason 7.3.4Provider reason 7.3.5

Following is an alphabetic list of parameters contained in this clause:

Absent Subscriber Diagnostic SM 7.6.8.9 Invoke Id 7.6.1.1Access connection status 7.6.9.3 ISDN Bearer Capability

IST Alert TimerIST Information WithdrawnIST Support Indicator

7.6.3.417.6.3.667.6.3.687.6.3.69

LCS Codeword 7.6.11.18LCS Codeword Applicability 7.6.11.19LCS Information 7.6.3.60LCS Service Type Id 7.6.11.15LCS Codeword Notification 7.6.11.22

Access signalling information 7.6.9.5 Kc 7.6.7.4

Additional Absent SubscriberDiagnostic SM

7.6.8.12 Linked Id 7.6.1.2

Additional Location Estimate 7.6.11.21 LMSI 7.6.2.16Additional number 7.6.2.46 Location Information 7.6.2.30

7/29/2019 NP-020358

16/49CR page 3

Location Information for GPRS 7.6.2.30aAdditional signal infoAdditional SM Delivery Outcome

7.6.9.107.6.8.11

Location update typeLong Forwarded-to NumberLong FTN Supported

7.6.9.67.6.2.22A7.6.2.22B

Age Indicator 7.6.3.72 Lower Layer CompatibilityLSA InformationLSA Information Withdraw

7.6.3.427.6.3.567.6.3.58

Alert Reason 7.6.8.8 MC Information 7.6.4.48Alert Reason Indicator 7.6.8.10 MC Subscription Data 7.6.4.47Alerting Pattern 7.6.3.44 Mobile Not Reachable Reason 7.6.3.51All GPRS Data 7.6.3.53 Modification request for CSI 7.6.3.81All Information Sent 7.6.1.5 Modification request for SS Information 7.6.3.82AN-apdu 7.6.9.1 More Messages To Send 7.6.8.7APN 7.6.2.42 MS ISDN 7.6.2.17Authentication set list 7.6.7.1 MSC number 7.6.2.11B-subscriber Address 7.6.2.36 MSIsdn-Alert 7.6.2.29B subscriber Number 7.6.2.48 Multicall Bearer Information 7.6.2.52B subscriber subaddress 7.6.2.49 Multiple Bearer Requested 7.6.2.53Basic Service Group 7.6.4.40 Multiple Bearer Not Supported 7.6.2.54Bearer service 7.6.4.38 MWD status 7.6.8.3BSSMAP Service Handover 7.6.6.5

Call Barring Data 7.6.3.83 NbrUser 7.6.4.45Call barring feature 7.6.4.19 Network Access Mode 7.6.3.50Call barring information 7.6.4.18 Network node number 7.6.2.43Call Direction 7.6.5.8 Network resources 7.6.10.1Call Forwarding Data 7.6.3.84 Network signal information 7.6.9.8Call Info 7.6.9.9 New password 7.6.4.20Call referenceCall Termination Indicator

7.6.5.17.6.3.67

No reply condition timer 7.6.4.7

Called number 7.6.2.24 North American Equal Accesspreferred Carrier Id

7.6.2.34

Calling number 7.6.2.25 Number Portability Status 7.6.5.14CAMEL Subscription Info 7.6.3.78 ODB Data 7.6.3.85CAMEL Subscription Info Withdraw 7.6.3.38 ODB General Data 7.6.3.9Cancellation Type 7.6.3.52 ODB HPLMN Specific Data 7.6.3.10Category 7.6.3.1 OMC Id 7.6.2.18CCBS Feature 7.6.5.8 Originally dialled number 7.6.2.26CCBS Request State 7.6.4.49 Originating entity number 7.6.2.10Channel Type 7.6.5.9 Override Category 7.6.4.4Chosen Channel 7.6.5.10 P-TMSI 7.6.2.47Chosen Radio Resource Information 7.6.6.10B PDP-Address 7.6.2.45Ciphering mode 7.6.7.7 PDP-Context identifier 7.6.3.55Cksn 7.6.7.5 PDP-Type 7.6.2.44CLI Restriction 7.6.4.5 Pre-paging supported 7.6.5.15CM service type 7.6.9.2 Previous location area Id 7.6.2.4Complete Data List Included 7.6.3.54 Protocol Id 7.6.9.7CS Allocation Retention priority 7.6.3.87 Provider error 7.6.1.3CS LCS Not Supported by UE 7.6.11.9 PS LCS Not Supported by UE 7.6.11.10CUG feature 7.6.3.26 QoS-Subscribed 7.6.3.47CUG index 7.6.3.25 Radio Resource Information 7.6.6.10

CUG info 7.6.3.22 Radio Resource List 7.6.6.10ARANAP Service Handover 7.6.6.6

CUG interlock 7.6.3.24 Rand 7.6.7.2CUG Outgoing Access indicator 7.6.3.8 Regional Subscription Data 7.6.3.11CUG subscription 7.6.3.23 Regional Subscription Response 7.6.3.12CUG Subscription Flag 7.6.3.37 Relocation Number List 7.6.2.19ACurrent location area Id 7.6.2.6 Requested Info 7.6.3.31

Requested Subscription Info 7.6.3.86Current password 7.6.4.21 Roaming number 7.6.2.19

Roaming Restricted In SGSN Due ToUnsupported Feature

7.6.3.49

Deferred MT-LR Data 7.6.11.3 Roaming Restriction Due ToUnsupported Feature

7.6.3.13

Deferred MT-LR Response Indicator 7.6.11.2 Current Security Context 7.6.7.8

eMLPP Information 7.6.4.41 Selected RAB ID 7.6.2.56Encryption Information 7.6.6.9 Service centre address 7.6.2.27Equipment status 7.6.3.2 Serving Cell Id 7.6.2.37Extensible Basic Service Group 7.6.3.5 SGSN address 7.6.2.39Extensible Bearer service 7.6.3.3 SGSN CAMEL Subscription Info 7.6.3.75

7/29/2019 NP-020358

17/49CR page 4

Extensible Call barring feature 7.6.3.21 SGSN number 7.6.2.38SNA Access Information 7.6.6.4

Extensible Call barring information 7.6.3.20 SIWF NumberSoLSA Support Indicator

7.6.2.357.6.3.57

Extensible Call barring information forCSE

7.6.3.79 SM Delivery Outcome 7.6.8.6

Extensible Forwarding feature 7.6.3.16 SM-RP-DA 7.6.8.1

Extensible Forwarding info 7.6.3.15 SM-RP-MTI 7.6.8.16Extensible Forwarding information forCSE

7.6.3.80 SM-RP-OA 7.6.8.2

Extensible Forwarding Options 7.6.3.18 SM-RP-PRI 7.6.8.5Extensible No reply condition timer 7.6.3.19 SM-RP-SMEA 7.6.8.17Extensible QoS-Subscribed 7.6.3.74 SM-RP-UI 7.6.8.4Extensible SS-Data 7.6.3.29 Sres 7.6.7.3Extensible SS-Info 7.6.3.14 SS-Code 7.6.4.1Extensible SS-Status 7.6.3.17 SS-Data 7.6.4.3Extensible Teleservice 7.6.3.4 SS-Event 7.6.4.42External Signal Information 7.6.9.4 SS-Event-Data 7.6.4.43Failure Cause 7.6.7.9 SS-Info 7.6.4.24Forwarded-to number 7.6.2.22 SS-Status 7.6.4.2Forwarded-to subaddress 7.6.2.23 Stored location area Id 7.6.2.5

Forwarding feature 7.6.4.16 Subscriber State 7.6.3.30Forwarding information 7.6.4.15 Subscriber Status 7.6.3.7Forwarding Options 7.6.4.6 Super-Charger Supported in HLR 7.6.3.70GGSN address 7.6.2.40 Super-Charger Supported in Serving

Network EntitySupported Camel4 SubsetsSupported Camel4 Subsets in GMSCSupported Camel4 Subsets in VMSCSupported Camel4 Subsets in VLRSupported Camel4 Subsets in SGSN

7.6.3.71

7.6.3.36D7.6.3.36E7.6.3.36F7.6.3.36B7.6.3.36C

GGSN number 7.6.2.41 Supported CAMEL Phases in VLR 7.6.3.36GMSC CAMEL Subscription Info 7.6.3.34 Supported CAMEL Phases in SGSN 7.6.3.36AGPRS enhancements support indicator 7.6.3.73 Supported GAD Shapes 7.6.11.20GPRS Node Indicator 7.6.8.14 Supported LCS Capability Sets 7.6.11.17

Suppress Incoming Call Barring 7.6.3.bGPRS Subscription Data 7.6.3.46 Suppress T-CSI 7.6.3.33

Suppress VT-CSI 7.6.3.aGPRS Subscription Data Withdraw 7.6.3.45 Suppression of Announcement 7.6.3.32GPRS Support Indicator 7.6.8.15 Target cell Id 7.6.2.8Group Id 7.6.2.33 Target location area Id 7.6.2.7GSM bearer capability 7.6.3.6 Target RNC Id 7.6.2.8AgsmSCF Address 7.6.2.58gsmSCF Initiated Call 7.6.3.cGuidance information 7.6.4.22 Target MSC number 7.6.2.12Handover number 7.6.2.21 Teleservice 7.6.4.39High Layer Compatibility 7.6.3.43 TMSI 7.6.2.2HLR Id 7.6.2.15 Trace reference 7.6.10.2HLR number 7.6.2.13 Trace type 7.6.10.3HO-Number Not Required 7.6.6.7 User error 7.6.1.4

IMEI 7.6.2.3 USSD Data Coding Scheme 7.6.4.36IMSI 7.6.2.1 USSD String 7.6.4.37Integrity Protection Information 7.6.6.8 UU Data 7.6.5.12Inter CUG options 7.6.3.27 UUS CF Interaction 7.6.5.13Intra CUG restrictions 7.6.3.28 VBS Data 7.6.3.40

VGCS Data 7.6.3.39VLR CAMEL Subscription Info 7.6.3.35VLR number 7.6.2.14VPLMN address allowed 7.6.3.48Zone Code 7.6.2.28

7/29/2019 NP-020358

18/49CR page 5


7.6.6 Radio parameters

7.6.6.1 - 7.6.6.34 Void


This parameter refers to the information element SNA Access Information information element defined in 3GPP TS

25.413.


8.4 Handover services

It should be noted that the handover services used on the B-interface have not been updated for Release 99. The B-

interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external

interface.

8.4.1 MAP_PREPARE_HANDOVER service

8.4.1.1 Definition

This service is used between MSC-A and MSC-B (E-interface) when a call is to be handed over or relocated fromMSC-A to MSC-B.

The MAP_PREPARE_HANDOVER service is a confirmed service using the primitives from table 8.4/1.

8.4.1.2 Service primitives

Table 8.4/1: MAP_PREPARE_HANDOVER

Parameter name Request Indication Response Confirm

Invoke Id M M(=) M(=) M(=)Target Cell Id C C(=)

Target RNC Id C C(=)HO-NumberNotRequired C C(=)IMSI C C(=)

Integrity Protection Information C C(=)Encryption Information C C(=)

Radio Resource Information C C(=)AN-APDU C C(=) C C(=)

Allowed GSM Algorithms C C(=)

Allowed UMTS Algorithms C C(=)Radio Resource List C C(=)

RAB ID C C(=)

BSSMAP Service Handover C C(=)

7/29/2019 NP-020358

19/49CR page 6

RANAP Service Handover C C(=)SNA Access Information C C(=)Handover Number C C(=)Relocation Number List C C(=)

Multicall Bearer Information C C(=)Multiple Bearer Requested C C(=)

Multiple Bearer Not Supported C C(=)

Selected UMTS Algorithms C C(=)

Chosen Radio ResourceInformation

C C(=)

User error C C(=)

Provider error O

8.4.1.3 Parameter use

Invoke Id

For definition of this parameter see clause 7.6.1.

Target Cell Id

For definition of this parameter see clause 7.6.2. This parameter is only included if the service is not in an ongoing

transaction. This parameter shall also be excluded if the service is a part of the Inter-MSC SRNS Relocation procedure

or the inter-system handover GSM to UMTS procedure described in 3G TS 23.009.

Target RNC Id

For definition of this parameter see clause 7.6.2. This parameter shall be included if the service is a part of the Inter-

MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3G TS 23.009.

HO-Number Not Required


IMSI

For definition of this parameter see clause 7.6.2. This UMTS parameter shall be included if:

S

available and

S

if the access network protocol is BSSAP and

S

there is an indication that the MS also supports UMTS.

Integrity Protection Information

For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if available and if the access

network protocol is BSSAP.

Encryption Information

For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if available and if the access

network protocol is BSSAP.

Radio Resource Information

For definition of this parameter see clause 7.6.6. This GSM parameter shall be included if the access network protocol

is RANAP and there is an indication that the UE also supports GSM. If the parameter Radio Resource List is sent , the

parameter Radio Resource Information shall not be sent.

AN-APDU


Allowed GSM Algorithms

7/29/2019 NP-020358

20/49CR page 7

For definition of this parameter see clause 7.6.6. This parameters includes allowed GSM algorithms. This GSM

parameter shall be included if:

the service is a part of the Inter-MSC SRNS Relocation procedure and

Ciphering or Security Mode Setting procedure has been performed.and

there is an indication that the UE also supports GSM.

Allowed UMTS Algorithms

For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if all of the followingconditions apply:

access network protocol is BSSAP and

Integrity Protection Information and Encryption Information are not available and

Ciphering or Security Mode Setting procedure has been performed.

Radio Resource List

For definition of this parameter see clause 7.6.6. This parameter shall be included if the access network protocol is

RANAP and there is an indication that the UE also supports GSM. This parameter shall be sent when MSC-A requests

multiple bearers to MSC-B. If the parameter Radio Resource Information is sent , the parameter Radio Resource List

shall not be sent.

RAB ID

For definition of this parameter see subclause 7.6.2. This parameter shall be included when MSC-A supports multiplebearers and access network protocol is BSSAP and the RAB ID has a value other than 1.

BSSMAP Service Handover

For definition of this parameter see clause 7.6.6. It shall be present if it is available.

RANAP Service Handover

For definition of this parameter see clause 7.6.6. It shall be present if it is available.

SNA Access Information

For definition of this parameter see clause 7.6.6. It shall be present if it is available and the UE is not currently involved

in an Emergency Call. This parameter shall not be included if the access network protocol is RANAP.

Handover Number

For definition of this parameter see clause 7.6.2. This parameter shall be returned at handover, unless the parameter

HO-NumberNotRequired is sent. If the parameter Handover Number is returned, the parameter Relocation Number List

shall not be returned.

Relocation Number List

For definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation, unless the parameter

HO-NumberNotRequired is sent. If the parameter Relocation Number List is returned, the parameter Handover Number

shall not be returned.

Multicall Bearer Information

For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation in the case that MSC-B

supports multiple bearers.

Multiple Bearer Requested

7/29/2019 NP-020358

21/49CR page 8

For a definition of this parameter see clause 7.6.2. This parameter shall be sent when MSC-A requests multiple bearers

to MSC-B.

Multiple Bearer Not Supported

For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation when MSC-B receives

Multiple Bearer Requested parameter and MSC-B does not support multiple bearers.

Selected UMTS Algorithms

For definition of this parameter see clause 7.6.6. This parameters includes the UMTS integrity and optionally

encryption algorithms selected by RNC under the control of MSC-B. This UMTS parameter shall be included if the

service is a part of the inter MSC inter system handover from GSM to UMTS.

Chosen Radio Resource Information

For definition of this parameter see clause 7.6.6. This parameter shall be returned at relocation if the encapsulated PDU

is RANAP RAB Assignment Response and MS is in GSM access.

User error

For definition of this parameter see clause 7.6.1. The following errors defined in clause 7.6.1 may be used, dependingon the nature of the fault:

- No handover number available.

- Target cell outside group call area;

- System failure.

- Unexpected data value.

- Data Missing.

Provider error

See definition of provider errors in clause 7.6.1.


17.7 MAP constants and data types

17.7.1 Mobile Service data types

7/29/2019 NP-020358

22/49


CR page 9

MAP-MS-DataTypes {

ccitt identified-organization (4) etsi (0) mobileDomain (0)

gsm-Network (1) modules (3) map-MS-DataTypes (11) version8 (8)}

DEFINITIONS

**** Unchanged text removed for clarity ****

-- handover types

ForwardAccessSignalling-Arg ::= [3] SEQUENCE {an-APDU AccessNetworkSignalInfo,

integrityProtectionInfo [0] IntegrityProtectionInformation OPTIONAL,

encryptionInfo [1] EncryptionInformation OPTIONAL,

keyStatus [2] KeyStatus OPTIONAL,

allowedGSM-Algorithms [4] AllowedGSM-Algorithms OPTIONAL,

allowedUMTS-Algorithms [5] AllowedUMTS-Algorithms OPTIONAL,radioResourceInformation [6] RadioResourceInformation OPTIONAL,

extensionContainer [3] ExtensionContainer OPTIONAL,

...,

radioResourceList [7] RadioResourceList OPTIONAL,

bssmap-ServiceHandover [9] BSSMAP-ServiceHandover OPTIONAL,

ranap-ServiceHandover [8] RANAP-ServiceHandover OPTIONAL }

AllowedGSM-Algorithms ::= OCTET STRING (SIZE (1))

-- internal structure is coded as Algorithm identifier octet from

-- Permitted Algorithms defined in 3G TS 48.008

-- A node shall mark all GSM algorithms that are allowed in MSC-B

AllowedUMTS-Algorithms ::= SEQUENCE {

integrityProtectionAlgorithms [0] PermittedIntegrityProtectionAlgorithms

OPTIONAL,

encryptionAlgorithms [1] PermittedEncryptionAlgorithms OPTIONAL,extensionContainer [2] ExtensionContainer OPTIONAL,

...}

PermittedIntegrityProtectionAlgorithms ::=

OCTET STRING (SIZE (1..maxPermittedIntegrityProtectionAlgorithmsLength))

-- Octets contain a complete PermittedIntegrityProtectionAlgorithms data type

-- as defined in 3G TS 25.413, encoded according to the encoding scheme

-- mandated by 3G TS 25.413.

-- Padding bits are included, if needed, in the least significant bits of the

-- last octet of the octet string.

maxPermittedIntegrityProtectionAlgorithmsLength INTEGER ::= 9

PermittedEncryptionAlgorithms ::=

OCTET STRING (SIZE (1..maxPermittedEncryptionAlgorithmsLength))-- Octets contain a complete PermittedEncryptionAlgorithms data type


-- mandated by 3G TS 25.413



maxPermittedEncryptionAlgorithmsLength INTEGER ::= 9

KeyStatus ::= ENUMERATED {

old (0),

new (1),

...}

-- exception handling:

-- received values in range 2-31 shall be treated as "old"

-- received values greater than 31 shall be treated as "new"

7/29/2019 NP-020358

23/49


CR page 10

PrepareHO-Arg ::= [3] SEQUENCE {

targetCellId [0] GlobalCellId OPTIONAL,

ho-NumberNotRequired NULL OPTIONAL,

targetRNCId [1] RNCId OPTIONAL,

an-APDU [2] AccessNetworkSignalInfo OPTIONAL,

multipleBearerRequested [3] NULL OPTIONAL,

imsi [4] IMSI OPTIONAL,

integrityProtectionInfo [5] IntegrityProtectionInformation OPTIONAL,

encryptionInfo [6] EncryptionInformation OPTIONAL,radioResourceInformation [7] RadioResourceInformation OPTIONAL,

allowedGSM-Algorithms [9] AllowedGSM-Algorithms OPTIONAL,

allowedUMTS-Algorithms [10] AllowedUMTS-Algorithms OPTIONAL,

radioResourceList [11] RadioResourceList OPTIONAL,


... ,

rab-Id [12] RAB-Id OPTIONAL,

bssmap-ServiceHandover [13] BSSMAP-ServiceHandover OPTIONAL,

ranap-ServiceHandover [14] RANAP-ServiceHandover OPTIONAL,

sna-AccessInformation [15] SNA-AccessInformation OPTIONAL

}

BSSMAP-ServiceHandover ::= OCTET STRING (SIZE (1))

-- Octets are coded according the Service Handover information element in

-- 3G TS 48.008.

RANAP-ServiceHandover ::= OCTET STRING (SIZE (1))

-- Octet contains a complete Service-Handover data type



-- Padding bits are included in the least significant bits.

RadioResourceList::= SEQUENCE SIZE (2..maxNumOfRadioResources) OFRadioResource

RadioResource ::= SEQUENCE {

radioResourceInformation RadioResourceInformation,

rab-Id RAB-Id,

-- RAB Identity is needed to relate the radio resources with the radio access bearers.

...}

maxNumOfRadioResources INTEGER ::= 7

SNA-AccessInformation ::= OCTET STRING (SIZE (5..maxNumOfSNAAccessInfoLength))

-- Octets contain a complete SNA Access Information data type





maxNumOfSNAAccessInfoLength INTEGER ::= 200

PrepareHO-Res ::= [3] SEQUENCE {

handoverNumber [0] ISDN-AddressString OPTIONAL,

relocationNumberList [1] RelocationNumberList OPTIONAL,

an-APDU [2] AccessNetworkSignalInfo OPTIONAL,multicallBearerInfo [3] MulticallBearerInfo OPTIONAL,

multipleBearerNotSupported NULL OPTIONAL,

selectedUMTS-Algorithms [5] SelectedUMTS-Algorithms OPTIONAL,

chosenRadioResourceInformation [6] ChosenRadioResourceInformation OPTIONAL,


...}

SelectedUMTS-Algorithms ::= SEQUENCE {

integrityProtectionAlgorithm [0] ChosenIntegrityProtectionAlgorithm OPTIONAL,

encryptionAlgorithm [1] ChosenEncryptionAlgorithm OPTIONAL,


...}

ChosenIntegrityProtectionAlgorithm ::= OCTET STRING (SIZE (1))

-- Octet contains a complete IntegrityProtectionAlgorithm data type

-- as defined in 3G TS 25.413, encoded according to the encoding scheme-- mandated by 3G TS 25.413


7/29/2019 NP-020358

24/49


CR page 11

ChosenEncryptionAlgorithm::= OCTET STRING (SIZE (1))

-- Octet contains a complete EncryptionAlgorithm data type




ChosenRadioResourceInformation ::= SEQUENCE {

chosenChannelInfo [0] ChosenChannelInfo OPTIONAL,chosenSpeechVersion [1] ChosenSpeechVersion OPTIONAL,

...}

ChosenChannelInfo ::= OCTET STRING (SIZE (1))

-- Octets are coded according the Chosen Channel information element in 3G TS 48.008

ChosenSpeechVersion ::= OCTET STRING (SIZE (1))

-- Octets are coded according the Speech Version (chosen) information element in 3G TS

-- 48.008

PrepareSubsequentHO-Arg ::= [3] SEQUENCE {

targetCellId [0] GlobalCellId OPTIONAL,

targetMSC-Number [1] ISDN-AddressString,targetRNCId [2] RNCId OPTIONAL,

an-APDU [3] AccessNetworkSignalInfo OPTIONAL,

selectedRab-Id [4] RAB-Id OPTIONAL,


...}

PrepareSubsequentHO-Res ::= [3] SEQUENCE {

an-APDU AccessNetworkSignalInfo,


...}

ProcessAccessSignalling-Arg ::= [3] SEQUENCE {an-APDU AccessNetworkSignalInfo,

selectedUMTS-Algorithms [1] SelectedUMTS-Algorithms OPTIONAL,

selectedGSM-Algorithm [2] SelectedGSM-Algorithm OPTIONAL,

chosenRadioResourceInformation [3] ChosenRadioResourceInformation OPTIONAL,selectedRab-Id [4] RAB-Id OPTIONAL,


...}

SelectedGSM-Algorithm::= OCTET STRING (SIZE (1))

-- internal structure is coded as Algorithm identifier octet from Chosen Encryption

-- Algorithm defined in 3G TS 48.008

-- A node shall mark only the selected GSM algorithm

SendEndSignal-Arg ::= [3] SEQUENCE {an-APDU AccessNetworkSignalInfo,


...}

SendEndSignal-Res ::= SEQUENCE {

extensionContainer [0] ExtensionContainer OPTIONAL,...}

RNCId::= OCTET STRING (SIZE (7))

-- The internal structure is defined as follows:

-- octet 1 bits 4321 Mobile Country Code 1st

digit

-- bits 8765 Mobile Country Code 2nd

digit

-- octet 2 bits 4321 Mobile Country Code 3rd

digit

-- bits 8765 Mobile Network Code 3rd

digit

-- or filler (1111) for 2 digit MNCs

-- octet 3 bits 4321 Mobile Network Code 1st

digit

-- bits 8765 Mobile Network Code 2nd

digit

-- octets 4 and 5 Location Area Code according to 3G TS 24.008

-- octets 6 and 7 RNC Id value according to 3G TS 25.413

RelocationNumberList::= SEQUENCE SIZE (1..maxNumOfRelocationNumber) OFRelocationNumber

MulticallBearerInfo ::= INTEGER (1..maxNumOfRelocationNumber)

7/29/2019 NP-020358

25/49


CR page 12

RelocationNumber ::= SEQUENCE {

handoverNumber ISDN-AddressString,

rab-Id RAB-Id,

-- RAB Identity is needed to relate the calls with the radio access bearers.

...}

RAB-Id ::= INTEGER (1..maxNrOfRABs)

maxNrOfRABs INTEGER ::= 255

maxNumOfRelocationNumber INTEGER ::= 7

RadioResourceInformation ::= OCTET STRING (SIZE (3..13))

-- Octets are coded according the Channel Type information element in 3G TS 48.008

IntegrityProtectionInformation ::= OCTET STRING (SIZE (18..maxNumOfIntegrityInfo))

-- Octets contain a complete IntegrityProtectionInformation data type





maxNumOfIntegrityInfo INTEGER ::= 100

EncryptionInformation ::= OCTET STRING (SIZE (18..maxNumOfEncryptionInfo))

-- Octets contain a complete EncryptionInformation data type





maxNumOfEncryptionInfo INTEGER ::= 100

**** Unchanged text removed for clarity ****


7/29/2019 NP-020358

26/49

CR page 1


CR-Form-v7

CHANGE REQUEST

= 29.010 CR 058 = rev 1 = Current version: 5.0.0 =



Title: = Support for Shared Network in connected mode

Source: = Ericsson



F (correction)A (corresponds to a correction in an earlier release)B (addition of feature),C (functional modification of feature)


Use one of the following releases:2 (GSM Phase 2)R96 (Release 1996)R97 (Release 1997)R98 (Release 1998)R99 (Release 1999)Rel-4 (Release 4)Rel-5 (Release 5)Rel-6 (Release 6)





During the Handover procedure the anchor MSC has to inform the non-anchorMSC about the SNA Access Information of the subscriber so that non-anchorMSC shall be able to forward this information to the Radio Network whenperforming subsequent intra-MSC handovers. The allowed SNAs are added toPrepareHandover.




Clauses affected: =

7/29/2019 NP-020358

27/49

CR page 2

Y N

Other specs=


29.002 CR 46623.003 CR 05023.009 CR 080

affected: X Test specificationsX O&M Specifications

Other comments: =


1) Fill out the above form. The symbols above marked = contain pop-up help information about the field that they areclosest to.



7/29/2019 NP-020358

28/49


CR page 3


4.5 Inter-MSC Handover

4.5.5 Processing in MSC-B, and information transfer on E-interface

The following parameters require processing (e.g. to store the parameter, to internally generate the parameter) in

MSC-B. The relevant BSSMAP procedures are mentioned to ease the comprehension, their detailed description is thescope of 3GPP TS 48.008. Each BSSMAP message listed in 3GPP TS 49.008 being transferred on E-interface shall use

the mechanisms given in subclause 4.5.4 and is described in 3GPP TS 48.008.

For intra-MSC-B handover/relocation and security interworking , after inter-MSC handover from GSM to GSM, the

3G_MSC-B needs additional information to be able to perform security mode and integrity protection procedures.

These RANAP informations are transferred between MSC-A and 3G-MSC-B in MAP messages, defined in 3GPP TS

29.002.


information to be able to perform service handover procedures. The relevant information is transferred between MSC-A

and 3G-MSC-B in MAP messages, defined in 3GPP TS 29.002.


information to be able to forward access rights information in the context of Shared Network to the RAN. The relevant

information is transferred between MSC-A and 3G-MSC-B in MAP messages, defined in 3GPP TS 29.002.







the Prepare Handover Request MAP message.


4.7 Inter-MSC Handover (GSM to UMTS)

7/29/2019 NP-020358

29/49


CR page 4

4.7.1 Basic Inter-MSC Handover

When a Mobile Station is handed over between two MSCs, the establishment of a connection between them (described

in 3GPP TS 23.009) requires interworking between A-Interface, Iu-Interface and E-Interface.

The signalling at initiation, execution and completion of the Basic Inter-MSC handover procedure is shown in figures

37 to 42 with both possible positive or negative outcomes.

Additionally figure 37b shows the possible interworking when the trace related message is transparently transferred on

the E-Interface at Basic Inter-MSC Handover initiation.

BSS-A MSC-A 3G-MSC-B| | ||HANDOVER | ||-------------->|MAP PREPARE HANDOVER ||REQUIRED |------------------------>| +----------------+| |request | |Possible Alloc. || | | |of a handover || | | |no. in the VLR-B|| | | +----------------+| | || | | RNS-B

| | | || | |RELOCATION REQUEST || | |------------------>|

Figure 37a: Signalling for Basic Inter-MSC Handover initiation (no trace related messagestransferred)

BSS-A MSC-A 3G-MSC-B| (*) ||HANDOVER | ||-------------->|MAP PREPARE HANDOVER ||REQUIRED |------------------------>| +----------------+| |request (**) | |Possible Alloc. || | | |of a handover |

| | | |no. in the VLR-B|| | | +----------------+| | || | | RNS-B| | | || | |RELOCATION REQUEST || | |------------------>|| | | || | |CN INVOKE TRACE || | |--------------->(***)

Figure 37b: Signalling for Basic Inter-MSC Handover initiation (CN invoke trace message transferred)

(*): Tracing invocation has been received from VLR.

(**): In that case, HANDOVER REQUEST and MSC INVOKE TRACE messages are included within theAN-apdu parameter.

(***): CN INVOKE TRACE is forwarded to RNS-B if supported by 3G_MSC-B.

Possible Positive outcomes: successful radio resources allocation and handover number allocation (if performed):

7/29/2019 NP-020358

30/49


CR page 5

BSS-A MSC-A 3G-MSC-B RNS-B| | | || | |RELOCATION REQUEST || | ||| | |CONTROL || | MAP PREPARE HANDOVER | || |

7/29/2019 NP-020358

31/49


CR page 6

BSS-A MSC-A 3G-MSC-B RNS-B| | | || | |RELOCATION COMPLETE|| | || || | |IU RELEASE COMMAND || | |------------------>|| | | |

Figure 42: Signalling for Basic Inter-MSC Handover completion (Negative outcome)

NOTE 2: From interworking between MAP and RANAP point of view, when the call is released.

BSS-A MSC-A 3G-MSC-B RNS-B| | | || | |LOCATION REPORT || | |

7/29/2019 NP-020358

32/49


CR page 7

----------------------------------------------------------------| 048.008 29.002 |Notes

--------22Forward | HANDOVER REQUIRED MAP PREPARE HANDOVER request|message | |

| -ho-NumberNotRequired| 1| BSSMAP information -target RNC Id || elements -IMSI |

| -Integrity protection|2| info || -Encryption info || -an-APDU( | 3| HANDOVER REQUEST, || MSC INVOKE TRACE) | 4

--------22Positive| MAP PREPARE HANDOVER response|result | | 5

| -handover number || -an-APDU( || HANDOVER REQUEST || ACKNOWLEDGE or || HANDOVER FAILURE) |

--------22Negative| HANDOVER REQUIRED REJECT MAP PREPARE HANDOVER| 6result | |

| equipment failure System Failure || equipment failure No Handover Number || available || equipment failure UnexpectedDataValue|| equipment failure Data Missing || || equipment failure MAP CLOSE || equipment failure MAP U/P -ABORT || |

NOTE 1: The ho-NumberNotRequired parameter is included by MSC-A, when MSC-A decides not to use anycircuit connection with 3G_MSC-B. No handover number shall be present in the positive result. Any

negative response from 3G_MSC-B shall not be due to handover number allocation problem.

NOTE 2: Integrity protection information, encryption information and IMSI parameters are included by MSC-A,

only when the MSC-A uses 29.002 as per release 99. These IEs are not included if the MSC-A is R98 or

earlier.

NOTE 3: The process performed on the BSSMAP information elements received in the HANDOVER REQUIRED

message is described in the 3GPP TS GSM Recommendation 048.008.

NOTE 4: The process performed on the BSSMAP information elements received in the MSC INVOKE TRACE

message is described in subclause 4.5.5.6.

NOTE 5: The response to the Prepare-Handover request can include in its an-APDU parameter, identifying the

GSM 08.06 protocol, either a BSSMAP HANDOVER REQUEST ACKNOWLEDGE or a BSSMAP

HANDOVER FAILURE.

In the first case, the positive result triggers in MSC-A the sending on A-Interface of the HANDOVERCOMMAND.

In the second case, the positive result triggers in MSC-A optionally the sending of the HANDOVER

REQUIRED REJECT.

(The possible sending of the HANDOVER REQUIRED REJECT message upon receipt of the

HANDOVER FAILURE is out of the scope of 3GPP TS 29.010 and lies in 3GPP TS 48.008).

NOTE 6: The possible sending of the HANDOVER REQUIRED REJECT message is described in3GPP TS

48.008.

The interworking between Prepare Handover and RELOCATION REQUEST in 3G_MSC-B is as follows:

7/29/2019 NP-020358

33/49


CR page 8

----------------------------------------------------------------| 29.002 25.413 |Notes

--------22Forward | MAP PREPARE HANDOVER RELOCATION REQUEST |message | request |

| -ho-NumberNotRequired || -target RNC Id || -IMSI |

| -Integrity protection info |1| -Encryption info || -RANAP service handover || -SNA Access Information SNA Access Information | 2| -an-APDU( || HANDOVER REQUEST, || MSC INVOKE TRACE) || || BSSMAP information RANAP information || elements: elements: || || Channel Type RAB parameters || Cause Cause || sRNC to tRNC container sRNC to tRNC container|| || info stored/generated || in/by 3G_MSC-B: || CN domain indicator || SNA Access Information|| |

--------22Positive| MAP PREPARE HANDOVER RELOCATION REQUEST ACK |result | response |

| -an-APDU( || HANDOVER REQUEST ACK) || || BSSMAP information RANAP information || elements: elements: || || Layer 3 info tRNC to sRNC container|| |

--------22Negative| MAP PREPARE HANDOVER RELOCATION FAILURE |

result | response || -an-APDU( || HANDOVER FAILURE) || |

NOTE 1: Integrity protection information, encryption information, IMSI and RANAP service handover parametersare included by MSC-A, only when the MSC-A uses 29.002 as per release 99. These IEs are not included

if the MSC-A is R98 or earlier.

NOTE 2: SNA Access Information parameter is included by MSC-A, only when the MSC-A uses 29.002 as per

release 5. These IEs are not included if the MSC-A is release 4 or earlier.

The interworking between Send End Signal and RELOCATION COMPLETE in 3G_MSC-B is as follows:

----------------------------------------------------------------| 25.413 29.002 |Notes

--------2

2Forward | RELOCATION COMPLETE MAP SEND END SIGNAL request |

message | || -an-APDU( || HANDOVER COMPLETE)|| |

--------22Positive| IU RELEASE COMMAND MAP SEND END SIGNAL response|result | -Normal release | 1--------22Negative| IU RELEASE COMMAND |result | -Normal release MAP CLOSE | 2

| -Normal release MAP U/P -ABORT|| |

NOTE 1: The positive empty result triggers the clearing of the Radio Resources on the Iu-Interface and the releaseof the SCCP connection between 3G_MSC-B and RNS-B. If a circuit connection is used between MSC-A

and 3G_MSC-B, the 'Normal release' clearing cause shall only be given to RNS-B when 3G_MSC-B has

received a clearing indication on its circuit connection with MSC-A.

7/29/2019 NP-020358

34/49


CR page 9

NOTE 2: The abortion of the dialogue or the rejection of the component triggers in 3G_MSC-B the clearing of its

circuit connection with MSC-A, if any, of the Radio Resources on the Iu-Interface and the release of the

SCCP connection between 3G_MSC-B and RNS-B.

The interworking between Send End Signal and CLEAR COMMAND in MSC-A is as follows:

----------------------------------------------------------------

| 29.002 048.008 |Notes--------22Forward | MAP SEND END SIGNAL CLEAR COMMAND |message | request |

| -an-APDU( - Handover || HANDOVER COMPLETE) Successful |


The interworking between HANDOVER FAILURE in case of reversion to old channel of the MS and User Abort in

MSC-A is as follows:

----------------------------------------------------------------| 08.0848.008 29.002

|Notes--------22Forward | HANDOVER FAILURE MAP U -ABORT |message | |

| - Reversion to old || channel |



4.7.4 BSSAP Messages transfer on E-Interface

The handling is described in chapter 4.5.4, additional cases are described in this chapter.

4.7.4.1 Assignment

The interworking between the BSSMAP assignment messages in MAP and the RANAP RAB assignment messages is

as follows:

7/29/2019 NP-020358

35/49


CR page 10

----------------------------------------------------------------| 29.002 25.413 |Notes

--------22Forward | MAP PREPARE HANDOVER RAB ASSIGNMENT REQ|message | request |

| -RANAP service Service handover || handover || -SNA Access SNA Access |

| Information Information || -an-APDU( || ASSIGNMENT REQUEST) || || BSSMAP information RANAP information || elements: elements: || || Channel Type RAB parameters || |

--------22Positive| MAP PREPARE HANDOVER |result | request |

| -an-APDU( || ASSIGNMENT COMPLETE RAB ASSIGNMENT || RESPONSE || or (positive result)|| ASSIGNMENT FAILURE) RAB ASSIGNMENT || RESPONSE || (negative result)|| || BSSMAP information RANAP information || elements: elements: || || Cause Cause |1| |

--------22Negative| |result | MAP U/P ABORT |

| |








the Prepare Handover Request MAP message .


7/29/2019 NP-020358

36/49


CR page 11

4.8 Inter-MSC Relocation

..


..






the Relocation Request RANAP message encapsulated in the Prepare Handover rRequest MAP message.


7/29/2019 NP-020358

37/49

CR page 1

3GPP TSG-CN4 Meeting #15 Tdoc N4-021082Helsinki, Finland, 29 July 2 August

3GPP TSG-CN1 Meeting #25 Tdoc N1-021789Helsinki, Finland, 29 July 2 August TTTdddooocccNNN111---000222111666888555

CR-Form-v7

CHANGE REQUEST

= 23.009 CR 080=

rev 1 = Current version: 5.1.0 =

ForHELPon using this form, see bottom of this page or look at the pop-up text over the=

symbols.


Title: = Support for Shared Network Area

Source: = Ericsson

Work item code:= TEI5 Date:= 2002-07-30


F (correction)A (corresponds to a correction in an earlier release)B (addition of feature),

C (functional modification of feature)D (editorial modification)Detailed explanations of the above categories canbe found in 3GPP TR 21.900.

Use one of the following releases:2 (GSM Phase 2)R96 (Release 1996)R97 (Release 1997)

R98 (Release 1998)R99 (Release 1999)Rel-4 (Release 4)Rel-5 (Release 5)Rel-6 (Release 6)

Reason for change: = RAN WG3 #30 agreed on a final solution for the support of Shared Networks inconnected mode in Release 5. Please see LS N1-021535 and the TR R3:012included.

The agreed solution is based on the concept of SNA which is basically a collectionof Location Areas.


The set of allowed SNAs, the Shared Network Area (SNA) information is signalledto the radio access network at the call set up to allow the radio access networkdecide which Location Area the subscriber may be handed over to at a later point.

Summary of change:= SNA information resides in the CN and is transferred to the radio access networkvia the Iu interface where it is used for selection of the target cell for handover.During the inter-MSC handover, the SNA information is sent from the anchor tothe non-anchor and passed to the radio access network by the non-anchor. Foremergency calls, SNA information does not apply. This CR specifies handling ofthe SNA information with respect to the handover/relocation.

Consequences if =

not approved:

Correct target for handover could not be selected for Shared Networks.

Clauses affected: = 3.1, 4.3.1, 4.4.1

7/29/2019 NP-020358

38/49

CR page 2

Y N

Other specs=


22.129, 25.413, 25.401, 25.423, 29.002,23.003, 29.010

affected: Test specificationsO&M Specifications

Other comments: = This CR was once presented at CN1#24 (N1-021430) for conditional approval.Since RAN WG3 could not reach to an agreement by the end of the CN1 meeting,the CR was withdrawn.

In this revision the terminology is aligned with those used in other specifications,i.e. SNA is used instead of access rights. Reference to TS 25.401 where SNAis briefly described is also added.


1) Fill out the above form. The symbols above marked=

contain pop-up help information about the field that they areclosest to.


3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specificationjust in front of the clause containing the first piece of changed text. Delete those parts of the specificationwhich are not relevant to the change request.

7/29/2019 NP-020358

39/49

CR page 3

7/29/2019 NP-020358

40/49


CR page 4

****************************** FIRST MODIFICATION *****************************************

2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present

document.

References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.

For a specific reference, subsequent revisions do not apply.

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (includinga GSM document), a non-specific reference implicitly refers to the latest version of that document in the same

Release as the present document.

[1] ITU-T Recommendation Q.118: "Abnormal conditions - Special release arrangements".

[2] 3GPP TS 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and

acronyms".

[2a] 3GPP TS 21.905: "3G Vocabulary".

[3] 3GPP TS 03.68: "Digital cellular telecommunications system (Phase 2+); Voice Group Call

Service (VGCS); Stage 2".

[4] 3GPP TS 05.08: "Digital cellular telecommunications system (Phase 2+); Radio Subsystem Link

Control".

[5] 3GPP TS 48.008: "Digital cellular telecommunications system (Phase 2+); Mobile Switching

Centre - Base Station System (MSC-BSS) Interface Layer 3 specification".

[6] 3GPP TS 08.58: "Digital cellular telecommunications system (Phase 2+); Base Station Controler -

Base Transceiver Station (BSC-BTS) Interface Layer 3 specification".

[7] 3GPP TS 09.08: "Digital cellular telecommunications system (Phase 2+); Application of the Base

Station System Application Part (BSSAP) on the E-interface".

[8] 3GPP TS 29.010: "Information Element Mapping between Mobile Station - Base Station System

(MS-BSS) and Base Station System - Mobile-services Switching Centre (BSS-MSC); Signalling

procedures and the Mobile Application Part (MAP)".

[9] 3GPP TS 22.129: "Handover Requirements between UMTS and GSM or other Radio Systems".

[10] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols;Stage 3".

[11] 3GPP TS 25.413: "UTRAN Iu interface RANAP signalling".

[12] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".

[13] 3GPP TS 25.303: "UE functions and inter-layer procedures in connected mode".

[14] 3GPP TS 25.331: "Radio Resource Control (RRC) Protocol Specification".

[15] 3GPP TS 29.108: "Application of the Radio Access Network Application Part (RANAP) on the E-interface".

[16] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies".

[17] 3GPP TS 23.135: "Multicall supplementary service; Stage 2".

[18] 3GPP TS 23.236: "Intra Domain Connection of RAN Nodes to Multiple CN Nodes".

7/29/2019 NP-020358

41/49


CR page 5

[19] 3GPP TS 23.221: "Architectural Requirements".

[20] 3GPP TS 25.401: "UTRAN Overall Description".

****************************** NEXT MODIFICATION *****************************************

3.1 Abbreviations

For the purpose of the present document, the following abbreviations apply:

3G_MSC A third generation MSC that supports the Iu interface and optionally the A interface

3G_MSC-A The controlling 3G_MSC on which the call was originally established

3G_MSC-B The 3G_MSC to which the UE is handed over in a Basic Handover

3G_MSC-B' The 3G_MSC to which the UE is handed over in a Subsequent HandoverBSC Base Station Controller

BSS Base Station System

BSS-A The BSS from which the MS is being handed over

BSS-B The BSS to which the MS is being handed overBTS Base Transceiver Station

GERAN GSM EDGE Radio Access Network ISC International Switching Centre

MS Mobile Station

MSC A second generation Mobile Services Switching Centre that only supports the A interface

MSC-A The controlling MSC on which the call was originally established

MSC-B The MSC to which the MS is handed over in a Basic Handover

MSC-B' The MSC to which the MS is handed over in a Subsequent Handover

RNC Radio Network Controller

RNS Radio Network Subsystem

SBSS Serving BSS

SNA Shared Network Area

SRNS Serving RNSUE A User Equipment is a terminal that supports USIM and the UMTS Uu interface

UE/MS A terminal that supports USIM, SIM, the Uu interface and the Um interface

USIM UMTS Subscriber Identity Module

Other abbreviations used in the GSM specifications are listed in 3GPP TS 01.04 [2] and 3GPP TS 21.905[2a].

7/29/2019 NP-020358

42/49


CR page 6


4.3.1 Role of 3G_MSC-A

In the Intra-3G_MSC handover/relocation case, the 3G_MSC-A (simply termed 3G_MSC) controls the call, the

mobility management and the radio resources before, during and after an Intra-3G_MSC handover/relocation. When

RANAP or BSSMAP procedures have to be performed, they are initiated and driven by 3G_MSC-A.

In a network implementing the "Flexible Iu interface for handover/relocation" option, 3G_MSC-A may optionally use a

global title based on the Global RNC-Id for the addressing of the Iu interface messages towards the target RNC.

For handover/relocation to an area where "Intra Domain Connection of RAN Nodes to Multiple CN Nodes" is applied,

3G_MSC-A can have multiple target CN nodes for each handover/relocation target in a pool-area as specified in 3GPPTS 23.236 [18].

In the case of intra-MSC handover of a speech call, 3G_MSC-A controls the transcoder in the core network. The

3G_MSC-A determines if a transcoder is required to be inserted or released in the CN.

In the case of Inter-3G_MSC relocation, 3G_MSC-A links out the transcoder.

In the Inter-3G_MSC relocation case, 3G_MSC-A is the 3G_MSC that controls the call and the mobility managementof the UE during the call, before, during and after a basic or subsequent relocation. When RANAP procedures related todedicated resources have to be performed towards the UE, they are initiated and driven by 3G_MSC-A. The

3G_MSC-A - 3G_MSC-B interface works as a 3G_MSC - RNS interface for the RANAP procedures. The Direct

Transfer signalling is relayed transparently by 3G_MSC-B between 3G_MSC-A and the UE.

During a successful relocation the order to perform location reporting at change of Service Area is not transferred to the

target RNS. In the Intra-3G_MSC-A relocation case, the 3G_MSC-A re-issues the Location Reporting Control towards

the target RNS. In the Inter-3G_MSC relocation case, 3G_MSC-A keeps the control of the Location Report Control

procedure. However, re-issuing the Iu-LOCATION-REPORTING-CONTROL messages due to subsequent Intra-

3G_MSC-B relocations is the responsibility of 3G_MSC-B.

During a basic relocation, 3G_MSC-A initiates and controls all the relocation procedure, from its initiation (reception of

Relocation Required from RNS-A on Iu-interface) until its completion (reception of Relocation Complete from3G_MSC-B on E-interface).

During a subsequent relocation back to 3G_MSC-A, 3G_MSC-A acts as an RNS towards 3G_MSC-B, which controls

the relocation procedure until the termination in 3G_MSC-A of the handover radio resources allocation (sending of the

Relocation Request Acknowledge to 3G_MSC-B from 3G_MSC-A). Then all relocation related messages shall

terminate at 3G_MSC-A (e.g. Relocation Detect/Complete from RNS-B, Relocation Cancel from RNS-A).

During a subsequent relocation to a third 3G_MSC, 3G_MSC-A works towards 3G_MSC-B' as described above in the

basic relocation paragraph and towards 3G_MSC-B as described above in subsequent relocation paragraph.

In the Inter-System, inter-3G_MSC handover case, 3G_MSC-A is the 3G_MSC which controls the call and the mobility

management of the UE/MS during the call, before, during and after a basic or subsequent inter-system handover. When

BSSAP procedures related to dedicated resources have to be performed towards the UE/MS, they are initiated and

driven by 3G_MSC-A. The 3G_MSC-A MSC-B interface works as a 3G_MSC BSS interface for a subset ofBSSMAP procedures. These BSSMAP procedures described in 3GPP TS 09 08 [7] are those related to dedicated

resources. The DTAP signalling is relayed transparently by MSC-B between 3G_MSC-A and the UE/MS.

During a basic inter-system UMTS to GSM handover, 3G_MSC-A initiates and controls all the handover procedure,

from its initiation (reception of Relocation Required from RNS-A on Iu-interface) until its completion (reception of

Handover Complete from MSC-B on E-interface).

During a subsequent inter-system UMTS to GSM handover back to 3G_MSC-A, 3G_MSC-A acts as a BSS towards

3G_MSC-B, which controls the handover procedure until the termination in 3G_MSC-A of the handover radio

resources allocation (sending of the Handover Request Acknowledge to 3G_MSC-B from 3G_MSC-A). Then all

handover related messages shall terminate at 3G_MSC-A (e.g. Handover Detect/Complete from BSS-B, Relocation

Cancel from RNS-A).

During a subsequent inter-system UMTS to GSM handover to a third 3G_MSC, 3G_MSC-A works towards MSC-B' as

described above in the basic inter-system handover paragraph and towards 3G_MSC-B as described above in

subsequent inter-system handover paragraph.

7/29/2019 NP-020358

43/49


CR page 7

During a basic inter-system GSM to UMTS handover, 3G_MSC-A initiates and controls all the handover procedure,

from its initiation (reception of Handover Required from BSS-A on A-interface) until its completion (reception of

Handover Complete from 3G_MSC-B on E-interface).

During a subsequent inter-system GSM to UMTS handover back to 3G_MSC-A, 3G_MSC-A acts as an RNS towards

MSC-B, which controls the handover procedure until the termination in 3G_MSC-A of the handover radio resources

allocation (sending of the Handover Request Acknowledge to MSC-B from 3G_MSC-A). Then all handover related

messages shall terminate at 3G_MSC-A (e.g. Relocation Detect/Complete from RNS-B, Handover Failure fromBSS-A).

During a subsequent inter-system GSM to UMTS handover to a third 3G_MSC, 3G_MSC-A works towards

3G_MSC-B' as described above in the basic inter-system handover paragraph and towards MSC-B as described above

in subsequent inter-system handover paragraph.

3G_MSC-A may assign a priority level defined as RAB parameter in 3GPP TS 25.413 [11] for each bearer. In case of

relocation of a multicall configuration the 3G_MSC-B or the target RNC shall select the bearers to be handed overaccording to the priority level, if the target cell is not able to accommodate all bearers. If a selection has to be made

between bearers of the same priority level, then the selection criteria are implementation dependent.

For network sharing (see 3GPP TS 25.401 [20], subclause 7.2.3) 3G MSC-A shall send the SNA information to

3G_MSC-B except for emergency calls.

If 3G_MSC-A supports the optional supplementary service Multicall (See 3GPP TS 23.135) and UE is engaged with

multiple bearers the following description applies:

- In the Intra-3G_MSC relocation case, the 3G-MSC-A tries to relocate all bearers to a new RNS.

- In the basic relocation case, the 3G-MSC-A tries to relocate all bearers to 3G_MSC-B. If 3G_MSC-A receives

an indication that the 3G_MSC-B does not support multiple bearers, then 3G_MSC-A shall be able to select one

bearer to be handed over according to 3GPP TS 22.129 [9] and tries again to relocate the selected bearer.

- In the subsequent relocation to a third 3G_MSC-B' case, the 3G-MSC-A tries to relocate all bearers to 3G_MSC-B'. If 3G_MSC-A receives an indication that the 3G_MSC-B' does not support multiple bearers, then 3G_MSC-

A shall be able to select one bearer to be handed over according to 3GPP TS 22.129 [9] and tries again to

relocate the selected bearer.

- In the Intra-3G_MSC inter-system UMTS to GSM handover case and the basic inter-system UMTS to GSM

handover case, the 3G_MSC-A shall be able to select one bearer to be handed over according to 3GPP TS

22.129 [9] and tries to handover the selected bearer.

- In all cases described above, 3G_MSC-A shall release some calls which has been carried by the bearers failedto set up in new RNS or the bearers not to be handed over.


4.4.1 Role of 3G_MSC-BIn the Intra-3G_MSC handover/relocation case, the 3G_MSC-B keeps the control of the whole Intra-3G_MSC

handover/relocation procedure. 3G_MSC-B notifies MSC-A or 3G_MSC-A of intra-3G_MSC-B InterSystem handover

and intra GSM handovers, by using the A-HANDOVER-PERFORMED message.

In case of intra-3G_MSC-B SRNS relocation, if security algorithms have been changed:

a) When encapsulated BSSAP is used on the E interface, the A-HANDOVER-PERFORMED message shall be

sent.

b) When encapsulated RANAP is used on the E interface, the Iu-LOCATION-REPORT message shall be sent.

On reception of an order to perform location reporting at change of Service Area from 3G_MSC-A, 3G_MSC-B shall

be responsible to re-issue the Iu-LOCATION-REPORTING-CONTROL message after subsequent Intra-3G_MSC-Brelocations/handovers. This shall be performed immediately after the successful completion of the Relocation Resource

Allocation procedure.

7/29/2019 NP-020358

44/49


CR page 8

In both cases, the selected UMTS algorithm(s) shall be indicated in the MAP-PROCESS-ACCESS-SIGNALLING

request.

In a network implementing the "Flexible Iu interface for handover/relocation" option, in the Intra-3G_MSC

handover/relocation case, 3G_MSC-B may optionally use a global title based on the Global RNC-Id for the addressing

of the Iu interface messages towards the target RNC.

For subsequent inter-MSC handover/relocation to an area where "Intra Domain Connection of RAN Nodes to Multiple

CN Nodes" is applied, 3G_MSC-B can have multiple target CN nodes for each handover target in a pool-area asspecified in 3GPP TS 23.236 [18].

The role of 3G_MSC-B is also to provide transcoder resources.

In the Inter-3G_MSC relocation case, the role of 3G_MSC-B (3G_MSC-B') is only to provide radio resources control

within its area. This means that 3G_MSC-B keeps control of the radio resources connection and release towards RNS-

B. 3G_MSC-B will do some pr

NP-020358

Documents

Transcript of NP-020358