TSGR3#2(99)201. TSG-RAN Working Group 3 (Architecture) Nynäshamn 15 th to 19 th March Agenda Item : 6.2. : RRC Message Transfer on Iur

Similar documents
TSGW3#2(99)173. TSG-RAN Working Group 3 meeting #2 Nynäshamn, Sweden, 15th 19th March Agenda Item:

UTRAN Procedures. MM procedures -> see MM slides CM procedures -> see CM slides

UTRAN Procedures. Elementary procedures. RRC connection release. Transaction reasoning

TSG-RAN Working Group 1 meeting #21 Busan, Korea, April 2001

3GPP TR V4.0.0 ( )

UMTS course. Introduction UMTS principles. UMTS Evolution. UMTS Project

New service standardisation approach

HSPA over Iur RAN Nokia Siemens Networks RU20 Feature Training

3GPP TS V7.2.0 ( ) - performs selective or soft combining of MTCH between the selected cell and the neighbouring cell.

Call Establishment and Handover Procedures of PS Calls using HSDPA

ETSI TS V3.0.0 ( )

ETSI TS V ( )

MME SGW PGW. 17-Feb-14 21:15 (Page 1) This sequence diagram was generated with EventStudio Sytem Designer -

3G TS V1.0.2 ( )

ETSI TS V5.0.0 ( )

New Orleans, Louisiana, USA, 3-6 December, Title CRs (Rel-5 only) to Agenda Item 7.3.5

3GPP TS V1.3.1 ( )

Comparison of RRC and MAC based methods of dynamic scheduling between users on the uplink

3GPP TS V8.0.0 ( )

3GPP TS V9.1.0 ( )

ETSI TS V ( )

3G/UMTS Complete Mobile Originated Circuit Switched Call Setup. July 2009, Turin

HSDPA Principles and configuration

3G/4G Mobile Communications Systems. Dr. Stefan Brück Qualcomm Corporate R&D Center Germany

Node B Configuration and Initial Cell Configuration Procedures

ETSI TS V ( )

3G TS V1.0.2 ( )

3GPP TR V3.2.0 ( )

3GPP TR V3.7.1 ( )

ETSI TS V4.1.0 ( )

3GPP TS V ( )

ETSI TS V3.1.0 ( )

3GPP TS V9.2.0 ( )

UMTS Addresses and Identities Mobility and Session Management

ETSI TS V4.2.0 ( )

ETSI TR V7.0.1 ( ) Technical Report

3GPP TR V6.1.0 ( )

ETSI TS V (201

ETSI TR V3.0.0 ( )

ENABLING NETWORK REDUNDANCY IN THE RADIO ACCESS NETWORK

ETSI TS V ( )

ETSI TS V4.4.0 ( )

3GPP TR V4.0.1 ( )

UMTS Universal Mobile Telecommunications System

ETSI TS V4.1.0 ( )

ETSI TS V4.3.0 ( )

3GPP TS V ( )

ETSI TS V (201

New service standardisation approach

ETSI TS V ( )

TSG-RAN Meeting #13 TSGRP#13(01) 0595 Beijing, China, 18-21, September, 2001

UMTS System Architecture and Protocol Architecture

ETSI TR V5.1.0 ( )

ETSI TS V ( )

ETSI TS V5.4.0 ( )

ETSI TS V5.1.0 ( )

3GPP TS V9.1.0 ( ) Technical Specification

ETSI TS V5.3.0 ( )

3GPP TS V ( )

Proposed Text for new TS [25.308]: UTRA High Speed Downlink Packet Access: Overall Description; Stage 2

3GPP TR V8.0.0 ( )

From approved WG2-contribution ref. [2], the following description was taken:

Handover principle and concepts

3GPP TS V6.8.0 ( )

ETSI TR V7.0.0 ( ) Technical Report

3GPP TS V7.2.0 ( )

NETWORK DIAGNOSTICS Testing HSDPA, HSUPA for 3G mobile apps

3GPP TR V ( )

3GPP TS V7.1.1 ( )

ETSI TS V ( ) Technical Specification

ETSI TS V3.3.0 ( )

3GPP TR V6.0.0 ( )

ETSI TS V ( )

ETSI TS V3.6.0 ( )

HSPA Overview NCN-EG-07 Course Outline for HSDPA/HSUPA/HSPA

ETSI TS V ( )

A New Soft Handover Mechanism using DCHs in 3GPP HSDPA Networks

Dual Connectivity in LTE

Temporary Document Page 2 - switches off, the allocated resources and PCC rules information of PDN GWs used by the UE in non- network will not be dele

HSDPA Mobility Enhancement Solution to Support Real-Time Delay Sensitive Services. Concept Document

3GPP TR V7.0.0 ( )

3GPP TS V8.0.0 ( )

ETSI TS V ( )

ETSI TS V5.3.0 ( )

ETSI TR V5.1.0 ( )

ETSI TS V7.3.0 ( ) Technical Specification

3GPP TS V7.1.0 ( )

LTE RAN Operation (ARI0001) Course Outline

Buletinul Ştiinţific al Universităţii "Politehnica" din Timişoara. Seria ELECTRONICĂ şi TELECOMUNICAŢII TRANSACTIONS on ELECTRONICS and COMMUNICATIONS

ETSI TS V ( )

ETSI TS V ( )

ETSI TS V5.3.0 ( )

3GPP TS V8.1.0 ( )

TSGS#27(05)0116. Tdoc!S Technical Specification Group Services and System Aspects Meeting #27, March 2005,Tokyo, Japan

D4.1: Layer 2 & 3 Simulation Platform Description

Performance evaluation of Dynamic Block Error target selection based on traffic types in High Speed Uplink Packet Access

3GPP TR V5.0.0 ( )

UNIK4230: Mobile Communications Spring Semester, Per Hj. Lehne

SA WG2 Temporary Document Page 2 - Besides these advantages, it is possible to use the based mechanism to consider aspects such as: Node capabilities

3G TS ( )

Transcription:

TSG-RAN Working Group 3 (Architecture) Nynäshamn 15 th to 19 th March 1999 TSGR3#2(99)201 Agenda Item : 6.2 Source Title Document for : NTT DoCoMo : RRC Message Transfer on Iur : Decision 1. Abstract This paper contributes to introduce RRC Message Transfer on RNSAP. RRC Message Transfer message is used to transfer the RRC messages, which are sent/received between Target RNC and UE, on Iur. 2. Discussion In case of Cell Update, UE will access to target RNC. The target RNC can be the different RNC from SRNC. In case of the target RNC is different from SRNC, the target RNC should inform SRNC that there was an access from UE which message indicates UE request for Cell Update. There are other cases that UE access other RNC than SRNC on RACH such as URA Update and RRC Connection Re-establishment. (It is FFS in TSG RAN WG2 whether RAB Release (DCH CCH), RAB Reconfiguration (DCH CCH), Transport CH Reconfiguration (DCH CCH) and Physical CH Reconfiguration (DCH CCH) are sent on RACH or not.) On assumption that there may be a case that CCH user plane exists on Iur, it is natural to assume that SRNC always decides whether SRNC Relocation is needed or not. Therefore Target RNC should not decide whether SRNC Relocation is needed or not. That implies that the message on Iur should not be SRNC Relocation Required. It should be only the transfer of the RRC messages. Therefore RRC Message Transfer on RNSAP (from target RNC to SRNC) is introduced.

If the RRC message is transferred from UE to RNC on RACH, the response message on FACH should use same MAC header value (FFS: SRNTI+SRNC ID or CN identity or Random Number) on the accessed cell, since RACH/FACH use same MAC header value. There may be a case in RRC Connection Re-establishment that the cell, which the dedicated CH is allocated, is different from the accessed cell. This occurs when UE is near the border of RNS serving areas and requests several candidate cells and there was no radio resource for accessed cell (Figure1). Therefore the response message should be transferred on Iur with RRC Message Transfer (from SRNC to target RNC).(arrow(7)) Procedure 1 Procedure 2 Handover Required / Relocation Required Handover Request / Relocation Request User Plane Setup Handover Command / Relocation Proceeding2 Handover Request Acknowledge / Relocation Proceeding1 Procedure 3 Procedure 4 Iu Release Command Handover Complete / Relocation Complete Iu Release Complete User Plane Release Figure 1 Figure 2 Figure2 shows the case in RRC Connection Re-establishment that the cell, which the dedicated CH is allocated, is same as the accessed cell. NTT DoCoMo proposes to use also RRC Message Transfer for arrow (7). The reason for this is based on the assumption that the signalling message between SRNC and UE should be directly transferred

through CRNC. If there is no CCH control plane exists on Iur, " RRC Message Transfer " should be transferred via CN. 3. Conclusion This paper contributes to introduce RRC Message Transfer on RNSAP. RRC Message Transfer message is used to transfer the RRC messages, which are used on RACH/FACH between UE and Target RNC, on Iur. Based on the discussion, NTT DoCoMo will prepare for the changes in the specification.

ANNEX1 ( for discussion) This annex is to clarify the procedure used in SRNC Relocation and Inter-RNS HHO. This annex is written on assumption that on the Iur interface, CCH user plane is accepted as an option. And also it is written on an assumption that Relocation Proceeding1 and 2 are needed.(both are study items and they depend on the result of discussion in WG3). A.1 Comparison of Flows There are several procedures which uses SRNC Relocation / Inter-RNS HHO. There are cases as shown below. (1) SRNC Relocation / Inter-RNS HHO with no access to UE. (2) SRNC Relocation / Inter-RNS HHO with trigger from UE. Case (1) is executed by SRNC and the timing is decided by SRNC. SRNC can execute this procedure at anytime. Case (2) is executed by SRNC with a triggering from UE. SRNC immediately execute this procedure. In both cases, Iu procedure is same (parameters may differ) as shown in Figure1. Procedure 1 Procedure 2 Handover Required / Relocation Required Handover Request / Relocation Request User Plane Setup Handover Command / Relocation Proceeding2 Handover Request Acknowledge / Relocation Proceeding1 Procedure 3 Procedure 4 Iu Release Command Handover Complete / Relocation Complete Iu Release Complete User Plane Release Figure 1 Common Procedure Between SRNC Relocation / Inter-RNS HHO

In Procedure 1, the difference between case (1) and case (2) is shown below. Case(1) Case(2) RRC message on RACH RRC Message (on RACH) Case(2) RRC message on DCH RRC Message (on DCH) In case (1), there is no RRC message. In case (2) with RRC message on RACH, the RRC message can be; - Cell Update - URA Update - RRC Connection Re-Establishment Request (Message shown below is FFS in WG2.) - Radio Access Bearer Release Complete (DCH CCH) - Radio Access Bearer Reconfiguration Complete (DCH CCH) - Transport CH Reconfiguration Complete (DCH CCH) - Physical CH Reconfiguration Complete (DCH CCH) If there is no Iur CCH control plane, this RRC message should be transferred via CN, which directly transfers to SRNC.(Needs to be discussed!) SRNC receives RRC message Transfer RNSAP message as if it is an RRC message. If SRNC decides to execute SRNC relocation, Procedure 2,3,4 are needed. If SRNC decides not to execute in case of CCH user plane exists on Iur interface, only procedure 3(shown later) is needed. In case (2) with RRC message on DCH, the RRC message can be inter-rns or inter-system HHO request (MEHO) or measurement report (NEHO). SRNC immediately decides to execute SRNC relocation and procedure 2,3,4 are needed. In Procedure 3, the difference between case (1) and case (2) is shown below. Case(1) Relocation Commit Case(2) RRC message on FACH RRC Message (on FACH) RRC Message (Necessity is FFS) Case(2) RRC message on DCH RRC Message (on DCH) RRC Message

In case (1), there is no RRC message. Only RNSAP message Relocation Commit is needed. In case (2) with RRC message on FACH, the RRC message can be; - Cell Update Confirm (allocation of new RNC ID and RNTI) - URA Update Confirm (allocation of new RNC ID and RNTI) - RRC Connection Re-Establishment (FFS) If there is no Iur CCH control plane, this RRC message should be transferred via CN, which directly transfers to Target RNC.(Needs to be discussed!) Target RNC receives RRC Message Transfer RNSAP message and directly transfers to UE. UE responds with RRC messages (necessity is FFS in WG2) using new RNTI on MAC header. In case (2) with RRC message on DCH, the RRC message can be; - Handover Command (Inter-RNS HHO, Inter-system HHO or etc) UE responds with RRC message (Handover Complete) on DCH using new physical radio resources (e.g. channelization codes). A.2 In case of CCH User plane exists on Iur Interface If CCH user plane exists on Iur Interface, the procedure for case (2) with RRC message on RACH/FACH will be the flow with combination of procedure 1 and 3 which shown below. Case(2) RRC message on RACH RRC Message (on RACH) Case(2) RRC message on FACH RRC Message (on FACH) RRC Message (Necessity is FFS) FFS