IL1 Call Management Introduction

IL1 Call ManagementFor internal use
Ding Junhua
For internal use
For internal use
For internal use
Wireless communication evolution
Frequency 1
Frequency 2
Frequency 3
MS1
MS1
MS1
MS1
MS1
MS2
MS2
MS2
MS2
MS2
MS3
MS3
MS3
MS3
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010
1001010100101010001010111010101010010001010111101010010010100010010000100
1001010100101010001010111010101010010001010111101010010010100010010000100
Z000RUZV (Z) - 3G: FDDTDDFDDTDD. FDDW-CDMAcdma2000TDDW-CDMATD-SCDMA TDD TS.
* © Nokia Siemens Networks Presentation / Author / Date
For internal use
UMTS Network Architecture
GSM/EDGE Access Network
For internal use
BTS service is ok.
RNC>MSC common connection is ok, RNC>BTS common connection is ok.(signalling level)
CELL has been setup. (including common channel has been setup and SI broadcasting is ok).
UE Power on
Cell selection/reselection: select frequency.
UE reads random access parameters from BTS and initiate the Radom access attempt.
System Registration (authentication…)
Enter IDLE state
RRC connection setup. (SRB setup,radio resource setup)
NAS procedure (CR, CC…) to setup the SCCP connection between CN>RNC.
RAB setup
Call connect.
Z000RUZV (Z) - 11
For internal use
Data path for SRB(FP sync)
Initial direct transfer:CM request(CR,DCH)
CN2
BTS
UE
RNC
CN1
RNC
BTS
UE2
Iub data path res prepare for RAB
Radio resource allocation for RAB
Iub data path setup for RAB(FP sync)
paging
Radio resource allocation
Iub data path res prepare for RAB
Radio resource allocation for RAB
Iub data path setup for RAB(FP sync)
Call connect
For internal use
RNC
RNC
RNC: Radio Network Controller
UTRAN
Z000RUZV (Z) - Core Network is responsible for switching and routing calls and data connections to external networks.
For internal use
MGW
Cell Site
Cell Site
SGSN
NodeB
NodeB
NodeB
NodeB
PSTN
For internal use
Logical channels
For internal use
For internal use
RNC (radio network controller)
The RNC (Radio Network Controller) is the network element responsible for the control of the radio resources of UTRAN.
It interfaces the CN (normally to one MSC and one SGSN) and also terminates the RRC (Radio Resource Control) protocol.
RNC role:
CRNC. The RNC controlling one Node B, it is the role for Node B.
Serving RNC. The SRNC for one mobile is the RNC that terminates both the Iu link for the transport of user data and the corresponding RANAP signalling to/from the core network.
Drift RNC. The DRNC is any RNC, other than the SRNC, that controls cells used by the mobile.
Z000RUZV (Z) - RNC1 is the CRNC for Node B 1. RNC2 is the CRNC for Node B 2. RNC1 is the SRNC for UE. RNC2 is the DRNC for UE.
CN1
RNC1
RNC2
Iu
Iur
For internal use
Management of radio channel configurations in RAN
Radio resource management
Can be initiated also by MS
Different types of handover: soft, softer, hard handover with intra & inter RNC handovers
Ciphering
Maintenance
Software updates in RNC and BTS
Operation
Modification of the radio access network
Configuration of RNC HW
Administration of RNC equipment
For internal use
mcRNC Network architecture
For internal use
ADA Network architecture
For internal use
The radio resource management is managed by RRM,RRC,NBAP in application.
Call management is responsible for data path setup/modify/release of Iu, Iur, Iub.
Following is example of AMR call data path:
For internal use
Call Management Concept
For internal use
What is call management
CM (Call Management) is part of IPA Light SW which provides an interface to switching resources and user plane resources to L3 application. In IPA Light, CM only provide services to mcRNC and ADA application software.
As ADA requirement is not clear currently, so this introduction will focus on mcRNC part.
CM provides a logical resource model, which gives to the clients a simplified view to the physical resources.
Call Management deals with call which maps to the user service, following services are supported:
Real Time speech
Signaling link data
Real Time data
For internal use
Call Management. (Such as Call Create, Call Release…)
Generic Connection Resource Management (Such as IP resource…)
Generic Service Management (Such as cell service)
Adaptation of different resources (IP connection, VCP connection…)
User Plane Resource Management
Owner ID management.

For internal use
For internal use
External transport resources.
In mcRNC, only IP network is supported, so the external resource are :
IP Iub (FP over IP + UDP)
IP Iur (FP over IP + UDP)
IP IuCS(RTP/RTCP over IP + UDP)
IP IuPS(data over IP + UDP +GTPU)
Internal transport resources
User Plane resources
In mcRNC, CSUP provide the UP service for common user (CELL, CCH…) and USUP provide the UP service for dedicated user (SRB, RAB…)
For internal use
Call Basic concept
For internal use
What is call
Call means all the resources between physical endpoints at the external interfaces.
Call is used for specific 3G service, such as SRB, common channel, RAB.
Call can be two-sided or multisided and it consists of legs and a leg connector and can contain up to16 legs.
The logical module of two-sided call:
For internal use
Relations and concepts
The CM handles the resources of a call (e.g. legs), but the resources seen in application layer are the logical resources.
The call can be two-sided call and multi-sided call, in RNC only two-sided call is supported.
The through switch connection means all the connections and recourses between physical endpoints at the external interfaces of the NE. The through switch connection is composed of legs and one leg connector. Typically, one through switch connection (one call) contains two legs – one for incoming side of a call and an other one for outgoing side of a call.
MDC (Macro Diversity Combining) service is logical service which can be added to a logical leg.
Resource Management
For internal use
.
1 call can have 0-32 connections, and 1 connection have 2 connection points which can be service or leg.
1 call can have 0-15 legs, and 1 leg can contain 0-1 dsp service.
call_id topology
For internal use
For internal use
Resource model : two-side call
up to 6 "sides" in a call (incoming, outgoing, termination, pre-allocated IN and OUT, and secondary IN(IN_SEC))
these "sides" can be branchable: multiple legs are supported (up to 6 per side)
only IN and OUT can be connected together (through connection)
pre-allocated legs are used for fast switching situations
Detailed description of the logical leg type:
in_c normal incoming logical leg, which can be used in through connection
out_c normal outgoing logical leg, which can be used in through connection
in_pre_c pre-allocated incoming logical leg, which is seized, but must be swapped before it can be used in through connection
out_pre_c pre-allocated outgoing logical leg, which is seized, but must be swapped before it can be used in through connection
term_c the termination of a multisided call.
in_sec_c establish the HSDPA DL connection
Two-sided call resource model:
Used in RNC and Rel'99 MGW: typical through connections.
(this resource model can be also used in A4.1 and newer releases)
Legs are divided to four types:
- incoming
- outgoing
-pre-allocated outgoing
Legs can be branchable legs: Iub/Iur legs in RNC can have several branches to the same 3G-UE (see Macro Diversity Combining).
Only incoming and outgoing legs can be connected.
Pre-allocated legs can be used in fast switching situations (e.g. handovers): the needed resources are allocated beforehand, and when the switching is needed, the normal leg and the pre-allocated leg are swapped (e.g. incoming -> pre_in and pre_in -> incoming). In the swap, only leg connector is changed.
RNC Call Framework
For internal use
What is leg
Leg is an abstraction of the real resources.
A leg is composed of services and sub connections between these services.
A leg has an unambiguous start point that is identified by TPI. These start points are used to identify legs. Start points of legs are visible to the client, but the detailed structure of legs is hidden from them.
A leg can contain 2 services max.
All information of leg is stored to leg packet.
In IPA Light, following legs are supported:
UDP leg
RTP leg
GTP leg
For internal use
What is service
Services are divided in two category, leg's services and other services (cell etc.).
A service is realized in a functional unit and has one (terminating service) or two termination points.
A service is added to a leg by making subconnections to the termination points of the service.
The supported services in IPA Light are:
Macro Diversity Combining (MDC)
Other services: cell_c, hsdpa_c.
For internal use
Connecting legs and services
Connection principle is flexible: any type of leg or service can be connected to any type of leg or service
Legs and services have special connection points which can be either
termination points, OR
Connection is called leg connector
Leg connector can be VCP connection (e.g. if UP-services are in different units),or dynamic link inside UPUP/CSUP.
Leg_1
Leg_2
connection
points
leg
connector
For internal use
For internal use
OMU
Hand Refreshing Service(RFRPRB)
LGUTIL
UMUTIL
UHAPRB
Resource Management Utilities (RMUTIL)
For internal use
CRH
The Generic Connection Resource Manager Program Block (RM2PRB) provides services for the call and resource management. It provides a common interface for the Layer 3–application programs to access the switching resources of the system.RM2PRB uses adaptation instance (LEMANA) to allocate the resources for the calls.
The Refresher of Hand's Time Supervision (RFRPRB) is a supervision program block. It provides service for hand process supervision. Each call in the system has an own Refresh Group, which consists of hand processes belonging to the same call. RM2PRB starts this Refresh Group, when the call is requested. All Layer 3–applications must join to this Refresh Group, so that they can be supervised as well.
The Distributed Leg Control Program Block (LEMANA) is adaptation instance, which provides selection of the IP-based resources (GTP or UDP legs). LEMANA also provides connection of given resources (e.g. connect two legs together).
The Resource Unit Handling Program Block (UHAPRB) takes care of the owner id handling, restart handling, unit state change handling…
The Resource Management Utilities Program Block (RMUTIL) takes care of simulating real application for RM2PRB.
The Leg Utilities Program Block (LGUTIL) is the service terminal counterpart for RMUTIL. LGUTIL commands RMUTIL and also inquires data from RM2PRB.
For internal use
(UPM)
UPM
The Local User Plane Resource Manager Program Block (LRMPRB) takes care of local user plane reservation, modification, release. LRMPRB is located in the Linux node of each processing unit, which contains a SE node for user plane processing. LRMPRB receives user plane resource allocation requests from LEMANA, and it always manage the logical user plane resources only from the SE node located to the same processing unit with LRM itself.
The centralized User Plane Resource Manager (RM3PBR) takes care of USUP/CSUP resource state management, and provide Diagnostics interface to UP resources. It keeps record on the user plane resource situation of each user plane processing unit on the basis of the information received from LRMPRB.
The user plane Utilities Program Block (UMUTIL) is the service terminal provided to configure and check the RM3PRB resources.
For internal use
Call Resource Handling
For internal use
Functionalities
Call Resource Handling (CRH) is a domain in IPA Light, which contains the needed software to setup (release) switching resources for calls.
Following functionalities are provided by CRH:
Call Management Services
For internal use
Call management services
Call Management handles the request related to one call. These services are used to start new calls, supervise ongoing calls and release calls.
This functionality provides a simplified call model for the clients, which helps to keep track of the resources.
The Call Management provides following functionalities:
Call identification provides for each call a unambiguous call identifier (call_id). The Call Management functionality allocates an new call id for each new call. The identifier is released after the call has ended.
Call setup allows clients to start new calls: the call gets a call id and the call supervision is started.
Call release functionality releases the call, when the last resource of that call is released. Call Management provides also mechanism to release the whole call (e.g. in error situations).
Call inquiries allows clients to examine the state of calls.
Call supervision ensures that the ongoing calls are working properly. It also supervises the client hand process related to the call. The call supervision releases call, when it detects problems with it.
For internal use
Generic Connection Resource Management services
The Generic Connection Resource Management services provides an interface to the switching resources for the client.
The basic resource is logical leg. The logical leg is identified by Physical Resource identifier (PRid). The following services provides seizuring and releasing of logical legs, connecting and disconnecting the logical legs, and several special services (e.g. adoption and swapping).
rm_resource_req_as, rm_resource_release_req_as, rm_resource_modification_req_as, rm_resource_swap_req_as, rm_resource_inquiry_req_as are CM provided services to the client, and following is the description:
Resource seizure allocates a new switching resource.
Resource release handles releasing of the seized resources.
Resource connections is used to connect two Logical Legs together to form a Through Connection.
Resource swapping provides fast switching when the client wants to rapidly changes the resource connections with minimum break in through connection.
Resource inquiries allows clients to examine the state of resource in a call.
Resource supervision ensures that the resources are eventually released, even in fault situations.
Client (USCP/CSCP)
E3FD leg_create_ack_s
4. RM2PRB updates resource tables.
3. RM2PRB allocates the logical leg and optional service (and optional connection to connection point) using correct Adaptation instance.
For internal use
Connecting legs and services
The logical model of resources has a special connection point, which is used when connecting resources. This connection point can be either:
UDP, the leg has an IP address and UDP port allocated when it was created. This IP address and UDP port must be used when the leg is connected to other resources.
GTP, the leg has a GTP tunnel ID allocated when it was created.The IP address and GTP tunnel ID must be used when the leg is connected to other resources.
Service, the leg/service has a special SPRM-service, which is used for the connection. This service can be connected inside the same unit to another service, or it can be connected to termination point (which is part of vcp connection to other unit).
There are four different ways to connect two resources:
connection inside UP-unit, direct connect.
connection inside EIPU-unit, direct connect.
connection with DMXMSG connection, take care by UP itself, not visible by CM.
connection with VCP connection.
For internal use
Generic Service Management services
The logical service is an abstraction of a physical service. The abstract service has following characteristics:
type: the type of service (CELL /HSDPA/ MDC)
res_char: the resource parameters (e.g. bitrates and packetsizes)
conn_points: one service can have one or two connection points. They are named 'in' and 'out‘
The Generic Service Management allows following requests to the resources:
Service allocation reserves needed resource for the service.
Service release handles releasing of the service's resources.
Service modification allows the client to modify the characteristics of the allocated resource.
Service connection handles the connections to other resource.
Client
3. RM2PRB requests service creation from LEMANA (leg_serv_create_as)
For internal use
The Adaptation services provide adaptation of different hardware technologies. All resources in different technologies are abstracted to a common logical leg-model.
The Adaptation services implements these logical concepts. The implementation is different in different technologies. Only Adaption of IP is supported in IPA Light.
In IPA Light the only adaptation instance in LEMANA. LEMANA is light weight TNSDL family.
RM2PRB CSCP
LEMANA CSCP
RMDPRB CSCP
IIPPRB CSCP
TACPRB CSCP
For internal use
UDP leg example
For internal use
Test Call Support
Test call functionality enables better fault traceability in our own labs as well as in operator’s network environments. Test call can be used in situations like:
When there is detected some problems for example in certain type of calls.
Before adding/replacing new processing units to the mcRNC, they can be first tested to detect data path quality inside mcRNC network element.
There are two types of test calls: Originated by the application (RNC/MGW) or originated by the LGUTIL service terminal command. The LGUTIL originated calls can be called also as internal test calls.
Test calls are presented in the test_call test_call_ind_t ; of the message from application.
For internal use
Resource supervision services
The resource supervision services provide release procedures for error cases like unit restarts and state changes. Resource supervision also provides mechanism to release hanging resources from the system.
USUP/CSUP
OMU
For internal use
Owner ID concept
Owner ID is allocated for each USCP/CSCP after startup, and the value will changed continuously.
When call is setup, ownerID is also transferred to resource owners which is related with this call.
Change Owner ID has release the hanging resource which happened in CP side.
Release Owner ID can release the hanging resource which happened in transport, and UP side.
Owner ID 1 Call 1 Call 2 Call 3 Call 4 Call 5
CP
UP
Owner ID 1 Call 1 Call 2 Call 3 Call 5 Call 6 Call 7
T&T
CP
UP
T&T
CP
Owner ID 2 Call 1 Call 2 Call 3 Call 4 Owner ID 1 Call 6
UP
Owner ID 2 Call 1 Call 2 Call 3 Call 5 Owner ID 1 Call 6 Call 7
T&T
For internal use
Owner ID change and release
The resources of RU internal, such as between RM2,LEMANA and TAC will not be considered in this release.
For traffic and transport resource only rm2 call has leg, this resource supervision is needed, for standalone GTP tunnel, it is not in the own ID management concept.
Own ID only managed in RM2, LRM and TAE which represent CP, UP and TT resources.
When receive own ID change, rm2 will loop the leg in the call, and get the start point, and send message to TAE to change the owner ID.
When release the old owner ID, UHAPRB will broadcast the release message to LRM and TAE, then to release LRM will release the UP resource and TAE will release the traffic resource.
Impact to current design:
CM will configure the TAE if there is leg created even it is DRNC leg.
TAE will create the table for one side routing.
Change owner ID will not go through the LEMANA, RM2 will directly contact TAE, LRM…
Release owner ID will not go through the LEMANA also.
For internal use
leg_failure_complete
loop to find all the calls containing the resources of this unit type/index, and send rm_call_release_req to related RM2 Hands.
leg_failure_complete
vcp_res_release_req_s
ack
ip_res_free_req_s
ack
RFRPRB
rfr_stop_refr_all_hans_req_s
ack
For internal use
For internal use
UP Resource Management
For internal use
User plane resource manager
The user plane management functionalities are for user plane services management, such as USUP service start/modify/stop, USUP selection, USUP failure indication… and the real user plane functionalities are data channels of voice announcements, voice packets, common channels, and dedicated channels.
The whole UP resource management feature consists of 4 entities – Physical UP resource manager (RMDPRB), local UP resource manager( LRMPRB) ,centralized logical UP resource manager (RM3PRB) and SPRM user interface (UMUTIL).
The centralized DSP Resource Manager (RM3PBR) and local UP resource manager (LRMPRB) take care of the logical DSP resource reservation during the leg creation. The RMDPRB takes care of the physical user plane resource allocation during the leg creation.
The managed resources of UP are:
USUP/CSUP
For internal use
Allocating Resources
Z000RUZV (Z) - 1. L3 application sends the call setup request. 2. CRH (Call resource handling) asks the local LRM to allocating the user plane resources and LRM return failure with error cause no available resource. 3. CRH asks for RM3 in CFCP for available UP which has resources, and RM3 will return back the unit index which has free UP resources. 4. CRH asks DEST LRM to reserve the UP resources. 5. CRH use the call related parameters to ask DEST RMDPRB to configure the user plane services. 6. RMD configure the L2 applications in USUP/CSUP. 7. If connection presented, RMD configure the transport agent in USUP/CSUP.
PU 0
For internal use
Work principle
CSCP only allocate the UP resource from CSUP in own unit.
The resource selected for the control applications are always from the USUP which locates at the same processing unit unless there is no enough resource in own processing unit.
The user plane resource management is transparently to the UP application.
LRM only manage the UP resources of own processing unit and RM3 manage all USUP resource state.
Interface between LRM and RM3 are:
Allocating: RM3PRB provide service to LRMPRB to select user plane resources from other processing unit also LRMPRB provide interface to RM3PRB to allocating user plane resource of same unit.
Notify: RM3PRB provide interface to LRMPRB to notify the state change of user plane resources.
For each unit, there are 2 thresholds (a: full b: free) to manage the own unit user plane resource status.
When own unit resources is > a and current status is “free”, LRMPRB will notify RM3PRB to change the own unit status to “full”
When own unit resources is < b and current status is “full”, LRMPRB will notify RM3PRB to change the own unit status to “free”
Normally “a” is >= “b” and both value can be configured with UMUTIL.
List: LRMPRB provide interface to RM3PRB to list the detailed resource information of own unit.
Release: When USUP/CSUP restart, LRMPRB provide interface to RM3PRB to release the resource related with the failure USUP/CSUP (owner ID release).
For internal use
For internal use
SRB concept
SRB is signaling radio bearer which is responsible for signaling data transfer in RNC, it is RRC message.
SRB is setup during RRC connection setup.
The RRC data is over RLC/MAC/FP/UDP/IP.
For internal use
UP service
For internal use
RM2PRB USCP
LEMANA USCP
RMDPRB USCP
NRM_QX USCP
IIPPRB USCP
TACPRB USCP
rm_ip_res_req_s (UDP,subnet_id)
For internal use
MDC service
call_id topology
For internal use
RM2PRB USCP
LEMANA USCP
RMDPRB USCP
NRM_QX USCP/CSCP
LRMPRB USCP
rm_ip_res_req_s (in_c)
For internal use
UE state change
UE state means UE RRC connection state which is the signaling connection between UE<-->RNC.
UE RRC connection state also means the RRC message transport over which channel.
When RRC connection is on DCH, there is dedicated IUB link for signaling data.
When RRC connection is on FACH, the signaling data is transferred on common channel.
RRC connection can be released only when RRC is on FACH or DCH state. so if RRC connection is on PCH we must first change the rrc state to FACH or DCH then to release this RRC connection.
Possible state changes and affect to cm:
IDLEDCH, IDLEFACH
-- SRB reconfiguration needed,1 leg created and connect the MDC service.
DCHIDLE,DCHPCH
-- SRB release needed.
DCHFACH
-- SRB reconfiguration needed, leg will be disconnect from MDC service then released.
For internal use
CS call concept
CS call is the basic service for user, it is for UE to make to voice call and cs data service.
AMR call is type of CS call which use the IuCS interface.
CS call can over DCH or HSPA.
For internal use
MDC service
UDP leg
logical leg
For internal use
connection ID 1 for RTP, connection ID 2 for RTCP
USUP unit, index
For internal use
PS Call concept
PS call is the data service for user, such as download, Browsing, internet access…
It used IuPS interface which connect to SGSN.
PS call can over RACH/FACH,DCH or HSPA.
For internal use
UDP leg
logical leg
For internal use
PS call setup on DCH message flow (inactive GTP)
Inactive GTP means that first GTP tunnel created without any call, then some data received to triggered the real resource creation.
Iub resource creation is same as CS call setup on DCH.
RM2PRB USCP
LEMANA USCP
RMDPRB USCP
NRM_QX USCP
IIPPRB USCP
IUGPRB SITP
rm_ip_res_req_s (GTP,subnet_id)
leg_create_req_s (GTP-leg)
Iug_create_gtp_tunnel_ack_s (dl_tei)
leg_create_req_s (gtp-leg)
For internal use
PS setup on FACH/RACH data path
The Iu resource is same as the PS on DCH, just without the Iub resource setup which already done when common channel setup.
The Iu and Iub connect is done by application itself.
For internal use
PS on HSPA data path
The Iu resource is same as the PS on DCH, just there are two Iub resources dedicated for uplink and downlink.
From call management point of view, 2 Iub leg are some especially the MAC protocol are different and the handover concept is different.
For internal use
handover
Soft Handover is one of the most interesting feature of the WCDMA operation
handover means transfer of user connection from one radio channel to other.
Hard Handover:
Hard handover means that all the old radio links in the UE are removed before the new radio links are established. Hard handover can be seamless or non-seamless. Seamless hard handover means that the handover is not perceptible to the user. In practice a handover that requires a change of the carrier frequency (inter-frequency handover) is always performed as hard handover.
Soft Handover
Soft handover means that the radio links are added and removed in a way that the UE always keeps at least one radio link to the UTRAN. Soft handover is performed by means of macro diversity, which refers to the condition that several radio links are active at the same time. Normally soft handover can be used when cells operated on the same frequency are changed.
In a typical UMTS system, the UE is in soft/softer handover around 50% of the time. One of the very important requirements for the soft/softer handover is that the frames from different cells should be within 50ms of each other or this would not work.
Softer handover
Softer handover is a special case of soft handover where the radio links that are added and removed belong to the same Node B (i.e. the site of co-located base stations from which several sector-cells are served. In softer handover, macro diversity with maximum ratio combining can be performed in the Node B, whereas generally in soft handover on the downlink, macro diversity with selection combining is applied.
For internal use
Soft handover introduction
Soft handover is initiated from the RNC and the core network is not involved in this procedure
When UE is in soft handover, at least UE will occupy 2 radio links
For internal use
Soft handover intra-RNC
For internal use
MDC service
UDP leg
logical leg
For internal use
Leg connetor
UDP leg
logical leg
For internal use
Intra-Frequency Hard Handover:
Intra-frequency hard handover is lossless for NRT radio bearer but it causes short disconnection of RT radio bearer. Intra-frequency hard handover is required to ensure handover between cells controlled by separate RNCs in situations when inter-RNC soft handover is not possible.
Inter-Frequency Hard Handover
Inter-frequency handover is lossless for NRT radio bearer but it causes short disconnection of RT radio bearer. Inter-frequency handover is required to support multiple carrier frequencies in the radio network.
Inter-System Hard Handover
RAN supports the following types of inter-system handover for Circuit switched (CS) services:
Handover from WCDMA to GSM
Handover from GSM to WCDMA
Impact to Call management
From call management point of view, the HHO for call management is:
Release the old leg.
Setup the new leg.
For internal use
SRNC relocation introduction
The SRNS relocation is used for moving the SRNC functionality from one RNC to another RNC closer to the User Equipment (UE) if the UE moves during the communication. Both the radio access network (RAN) and the core network are involved.
Regarding the UEs mobility it is really the handovers that count. The SRNS relocation procedures can be seen as a subset for handover procedures: there are handovers without SRNS relocation but no SRNS relocations without handovers.
UE-not-involved relocation VS UE-involved relocation.
UE-not-involved: Iur interface exist, SHO
UE-involved: Iur interface not exist, HHO : 1.inter-frequncy 2.Iur not available 3.Iur not configured.
UE not involved SRNC relocation has not affect CM as for source SRNC, it is normal call release procedure, and for dest SRNC, it is normal call setup procedure, we only need to care one thing that is PS NRT relocation downlink data buffering.
For internal use
SRNC relocation introduction
There are 2 kinds of SRNC relocation in 3GPP as following, in NSN implementation, we only support the scenario 2, scenario 1 supported only in IHSPA.
For internal use
SRNC:
Before relocation, there is 1 in Iur leg and 1 service for srb.
After relocation, the SRB leg will be removed.
DRNC
Before relocation, there are 2 legs for SRB, one 1 in leg, another is out leg and 1 connection between in and out leg.
Relocation prepare phase: setup 1 standalone MDC service (in_pre leg setup).
Relocation commit: swap the service with the connect the in leg to MDC. release the iur leg.
After relocation, there is 1 leg, 1 service and 1 connection for SRB.
Relocation cancellation:
For internal use
SRNC:
Before relocation, there is 1 in Iur leg, 1 out Iu leg and 1 service for CS RAB.
After relocation, all resources will be removed.
DRNC
Before relocation, there are 2 legs for CS RAB, one 1 in leg, another is out leg and 1 connection between in and out leg.
Relocation prepare phase: setup 1 iu leg which include 1 rtp leg, 1 MDC service and 1 connection between leg and service(out_pre leg setup).
Relocation commit: swap the out_pre leg with the out leg(Iur) . release the original Iur leg.
After relocation, there is 2 leg, 1 service and 2 connection for CS RAB.
For internal use
SRNC:
Before relocation, there is 1 in Iur leg, 1 out Iu leg and 1 service for PS RAB.
After relocation, all resources will be removed.
DRNC
Before relocation, there are 2 legs for PS RAB, one 1 in leg, another is out leg and 1 connection between in and out leg.
Relocation prepare phase: setup 1 iu leg which include 1 gtp leg, 1 MDC service and 1 connection between leg and service(out_pre leg setup).
Relocation commit: swap the out_pre leg with the out leg(Iur) which means reconnect the in leg to MDC service and release the original Iur leg.
After relocation, there is 2 leg, 1 service and 2 connection for PS RAB.
For internal use
For internal use
Before relocation, there is no Iub connection in source RNC.
There is one Iur link

IP+PORT 2ß>IP+PORT3
IP+PORT 1 ß>connection ID 2 RNC TEID2 ß>connection ID 1
SGSN
For internal use
PS DL Data buffering during relocation(2)
Prepare the resources in DRNC side, pre Iu leg (GTP tunnel created and USUP service in created) is created in DRNC.

EITP
UE
SGSN
SGSN TEID1
RNC TEID2
IP+PORT 2ß>IP+PORT3 RNC TEID3 ß>connection ID 3
IP+PORT 1 ß>connection ID 2 RNC TEID2 ß>connection ID 1
RNC TEID3
For internal use
Before DRNC switch to SRNC, the preparation is needed in source RNC side.
The downlink data will pre-block by GTP forward tunnel (means the DL data from SGSN will not goto TAE but directly go to Target RNC TEID 3.)
Forward tunnel is only from source to destination, it is not by-direction.

TARGET RNC
SOURCE RNC
SGSN TEID1
RNC TEID2
IP+PORT 2ß>IP+PORT3 RNC TEID3 ß>connection ID 3
TAE:IP+PORT 1 ß>connection ID 2 RNC TEID2 ß>connection ID 1
RNC TEID3
For internal use
The target RNC begins to act as SRNC.
Buffering data can be sent to UE now.

TARGET RNC
SOURCE RNC
SGSN TEID1
RNC TEID2
IP+PORT 2ß>connection ID 4 RNC TEID3 ß>connection ID 3
RNC TEID3
For internal use

TARGET RNC
SOURCE RNC
SGSN TEID
RNC TEID2
RNC TEID3
For internal use
All resources in original SRNC will be released.
The Iur resource in target SRNC will be released.

SGSN TEID
RNC TEID3
For internal use
HSPA serving cell change
As UE can only receive the HSDPA traffic from one HS-DSCH channel so the handover concept is different for HSDPA users.
An example of inter-BTS SCC:
1.reconfigure the original BTS to remove the UE from the HSDSCH.
2. reconfigure the target BTS to add the UE from the HSDSCH.
3.setup the data path for downlink.
from cm pov, it is in_sec leg branch add.
4.reconfigure the source BTS to remove the UE from HS-DSCH.
5.reconfigure the target BTS to add the UE to HS-DSCH.
6.reconfigure the UE to update the active set to receive downlink packet from new HS-DSCH.
7.remove the original downlink data path, from cm pov, it is original in_sec leg branch remove
UE
Src Node B
User Plane setup
UE in CELL_DCH state, NRT RB mapped to HS-DSCH,
NBAP: RADIO LINK RECONFIGURATION PREPARE
NBAP: RADIO LINK RECONFIGURATION READY
NBAP: RADIO LINK RECONFIGURATION COMMIT (CFN)
RRC: MEASUREMENT REPORT (CPICH Ec/No,CPICH RSCP)
NBAP: RADIO LINK RECONFIGURATION READY
RNC initiates inter-BTS serving HS-DSCH cell change
NBAP: RADIO LINK RECONFIGURATION COMMIT (CFN)
At a time CFN – PreCFNSwitchTime RNC stops the MAC -d flow to old BTS and makes the capacity request to new BTS and starts the the MAC – d flow.
UE Starts Tx/Rx for HS-DSCH in target BTS and stops Tx/Rx for HS-DSCH in source BTS at the given activation time
User Plane release
For internal use
For internal use
For internal use
from LEMANA (leg_serv_create_as)
+ optional connection)
E3FD leg_create_ack_s
optional service (and optional connection to
connection point)
IMSI analysis, user data
get&analysis, security mode,
Iub data path
Iub data path
UE
UP
service
Iug_create_gtp_tunnel_ack_s (dl_tei)
Logical traffic
resource reservation
connection ID 1 for RTP, connection ID 2 for RTCP
USUP unit, index
-
to new BTS and starts the the
MAC
the resources of this unit type/index,
and send rm_call_release_req to
TARGET RNC
SOURCE RNC
TAE:IP+PORT 1 ß>connection ID 2
RNC TEID2 ß>connection ID 1
RNC TEID3
IP+PORT 1 ß>connection ID 2
After receive the relocation command in source RNC
TARGET RNC
SOURCE RNC
RNC TEID3
TARGET RNC
SOURCE RNC
RNC TEID3
RNC
IP+PORT 1 ß>connection ID 2
RNC TEID3
RNC TEID3

IL1 Call Management Introduction

Documents

Transcript of IL1 Call Management Introduction