3g 4g InterworkingSupport

ALU UTRAN GPS Support to AT&T 3G->4G
Inter-working for LTE Launch
ALU UTRAN GPS

Date: (Oct. 18, 2011)
3G-4G Inter-working Markets & issues
3G supporting AT&T 4G commercial launch is a broad topics. With a limited

knowledge from LTE, and extensive E2E system coverage required, this
presentation is not intended to provide LTE training, it assume audience has
UTRAN experience and only UMTS side supports/troubleshoot are discussed.
The AT&T initial targeted LTE commercial launch markets are:
BaWa (Baltimore & Washington), NY (New York), PHX (Phoenix), KC (Kansas),
STL (St. Louis).
The issues have been identified from past few months are:
SIB19 parameter modification (reduce T-Reselection threshold (DRX) and remove 2nd eARFCN);
4G->3G IRAT failure due to RAU Request Reject, which has 4 flavors;
St Louis 4G UE RAU issue(2G->3G): Samsung device plus Ericsson SGSN bug uncovered;
4G UE Drive test result shown percentage time spent on LTE did not meet the target
(main issue identified as UL data stall in TCP/IP server, starting from LTE MO call);
3G & 4G share same transport layer: SIAD(7705) and MSN(7750), it may cause
3G lose BW usage to impact 3G performance.
2 | ALU 3G -> 4G Interworking Support | Oct 2011
All Rights Reserved Alcatel-Lucent 2011
V7.1.3 RNC releases introduced LTE Cell-Reselection to support LTE

Starting from v7.1.3, 3G UTRAN supports 3G->4G Cell-Reselection and 4G->3G
Blind IRAT. 3G->4G Cell-Reselection via SIB19 is shown in next page and the detail
can be found in 3GPP standard and ALU UPUG document. During pre-commercial
deployment period, as 4G UE(s) are developed in same time, many UE issues were
identified and fixed. Same for CN - Core network SGSN has to support 4G device
and protocol, and issues found and fixed. AT&T has addressed 3rd party issues in
different topics and emails.
From 3G RNC/Nodeb, to date, no UMTS network problems identified from this
support effort, even we provided tuning to some of RNC/Nodeb parameters to
facilitate the LTE commercial launch.
After discussion of above issues, recommendation to RF drive test is provided if
other market requires to run drive test to debug issue(s).
RNC Logs, traces, tools and analyzers to support this activity.
Special thanks to GPS team: Bob Colby, Kee Yau, Denis Dugan, Tony Lai, Dan
Wagner, Jay Gao, Rajeev Rastogi, Dhimant Shah participated the activities, and
provided strong support to 3G-4G inter-working issues.
Mobility between UMTS and LTE Cell Reselection
CELL DCH
1. 3GPP Standards
E-UTRA
RRC CONNECTED
Handover
CELL FACH
Connection
Establishment/release
CELL PCH
URA PCH
Connection
Establishment/release
UTRA Idle
Reselection
Reselection
E-UTRA
RRC IDLE
OMC-R
UMTS SIB19 configuration
SIB19 Management
RNC
NB
SIB19 Broadcast
TS 25.304, 25.133, 25.331, 23.401
UMTS Sib19 was introduced in3GPP TS 25.331 v8.4.0.
2. Overview
Cell Reselection between UMTS & LTE is based on

SIB19 newly introduced in 3GPP R8
Applicable to FDD serving & LTE Frequencies
Eligible in UE Idle, URA_PCH & CELL_PCH Modes
Bidirectional reselection in Idle Mode
Unidirectional reselection for URA_PCH &

CELL_PCH from UMTS to LTE
RNC
Iub
UE
eNB
UE
SIB19 Contains
UTRA Priority Info List
Priority
Sprioritysearch1, Sprioritysearch2, Threshserving low
E-UTRA Priority Info List
Earfcn
Bandwidth
Priority
Qrxlevmin, Threshx high, Threshx low, E-UTRA detection

As AT&T LTE does not support voice yet, so a CS+PS call (DV) will be IRATed to
3G, UE preferably returns back to 4G if CS call terminated and 4G presented. In
other scenario, a PS call (DO) will be required to cell-reselect back to 4G once
LTE coverage is available. The decision to 4G are depended on: eNodeb signal,
Cell-Reselection thresholds (time and signal quality), UE reads SIB19, etc.
In current RNC release, only when UE moved to Idle state, the Cell-Reselection
will occur if arriving in LTE coverage (eNodeb presented in SIB 19) and its signal
strength qualified. Attached are documents from Feture81436, presented by
Sree Bollam, and 3GPP SIB definition. Cell-Reselection general guideline is
shown as below.
Measurement Criterion:
The UE shall perform measurements of inter-RAT layers with a priority higher than the
priority of the current serving cell
Cell Reselection Criterion:
SrxlevnonServingCell,x of a cell on an evaluated higher absolute priority layer is greater
than Threshx,high during a time interval Treselection
SrxLev
Newcellreselected
LTECell
UMTS Cell
Threshx,high
sNonIntraSearch= 2
Treselection: ~13 s in lab
time
D:\Works \DFS\
v7.1.3_FFA\PM81436 FA UMTS
3GPP_SIB
During Treselection, UE constantly measures signal from target LTE cell which evaluated as
absolutely higher priority layer, only all measurements meet Threshx.high, then CellReselection will occur. In page 11, it shown an example of Cell-Reselection call sequence.
As we want to favor LTE coverage, threshx,high is set to the higher value above sNonIntraSearch ( 4)
As Threshx,High and Treselection are key parameters to Cell-Reselection, ATT

requests that LTE-Reselection-threshold is set to -104dBm (AR 1-3447636/ CR
536120 ). This is the sum of (qRxLevMinETURA + threshx.High). Presently AT&T
LTE threshold for IRAT blind redirection to umts is set to -110dBm. They want a
6dB difference for LTE reselection, to avoid ping-pong on one end and not to have
a big gap on the other. Therefore, with qRxLevMinEUTRA set to -120dBm, the
Threshx.High is set to 8 (16 dB above qRxLevMinEUTRA), which gives:
-120dBm + (8x2)dBm = -104 dBm -> Threshx.high
Two major issues were raised during BaWa/PHX LTE integration:
1. Is Treselection time too long to delay UE cell-reselect to LTE.
2. Is SIB19 properly setup & transmitted to indicate to UE for a Cell-Reselection;

DRX cycle parameters from RNC are reduced to accelerate cell reselection, which provides a
reduced Treselection period. Examples for AT&T Belt RNCs.
Per FDDcell:
(RNC=BTVLMD18CRARnn/NodeB=MDUnnnnn/FDDCell=MDUnnnnnn),csDrxCynLngCoef=7
(RNC=BTVLMD18CRARnn/NodeB=MDUnnnnn/FDDCell=MDUnnnnnn),psDrxCynLngCoef=7
Per RNC:
(RNC=BTVLMD18CRARnn/RadioAccessService=0),utranDrxCycLngCoef=7
In next pages, SIB19 message contents are shown and its example after that.

SIB 19 message construct
UTRA priority info list
Priority
SprioritySearch1 : Srxlev of the UTRA cell used for neighbor measurement triggering.
SprioritySearch2 : Squal of the UTRA cell used for neighbor measurement triggering
ThreshServingLow : RSCP threshold of the UTRA cell used by the UE reselection process
EUTRA priority info list
EARFCN
Measurement Bandwidth
Priority
Qrxlevmin : (RSRQ) of the E-UTRA cell used for S criteria of the reselection process
ThreshXHigh : RxLev (RSRP) Threshold of the E-UTRA cell used by the UE reselection process
ThreshXLow : RxLev (RSRP) Threshold of the E-UTRA cell used by the UE reselection process
E-UTRA detection : TRUE means that the UE may detect the presence of a E-UTRA cell and report to NAS
SIB 19 parameters in RNC
RNC/RadioAccessService/isSib19Allowed,
RNC/Nodeb/FDDCell/sib19Enable,
RNC/Nodeb/FDDCell/reserved4,5,6,7. (detail encoding is in previous attachment, or ALU UPUG)

FDDCell reserved4 = 134679048
FDDCell reserved5 = 169023124 <-- contains earfcn[0]=5780
FDDCell reserved6 = 168429695 <-- contains earfcn[1]=2175
FDDCell reserved7 = 268701700

SIB19 from BaWa: MDU2332, MDU0496, and PHX: AZPHU0039

Cell-Reselection example in BaWa
7:37:12 UMTS Redirection
7:37:17 UMTS Origination
7:38:12 RRC Release cause User_Inactivity
7:38:16.777 LTE Measurement -76 RSRP
7:38:24 UMTS Origination (8 seconds since measurement)
7:39:12 RRC Release cause User_Inactivity
7:39:16.441 LTE Measurement -73 RSRP
7:39:23.469 UMTS Origination (7 seconds since measurement)
7:39:41.572 RRC Release cause User_Inactivity
7:39:44.595 LTE Measurement -107 RSRP -114 RSRP
7:39:54.347 UMTS Origination (10 seconds since measurement but inadequate signal so we would
NOT have reselected)
7:40:16.550 RRC Release cause User_Inactivity
7:40:20.297 LTE Measurement -94 RSRP (meet threshx.high)
7:40:30.510 LTE Measurement -90 (meet threshx.high)
7:40:30.577 Successful LTE Reselection

SIB 19 message can be verified from Nodeb saveState log, where it shown in each
Cell SIB IEs. Both v7.1.3 FOA/FFA test data shown:
SIB19 broadcast every 640ms nominally as defined in SchedulingInfo
SIB19 repetition will be no slower than 2560ms
UMTS to LTE Reselection possible in Idle and URA_PCH, not in Cell_FACH
SIB19 change indicated to a UE in Cell_FACH with Sys Info Change
Driving from UMTS only to UMTS+LTE coverage in Idle mode:

Time from last reselection attempt to TAU (Track Area Update) Accept: ~8 seconds
Driving from UMTS only to UMTS+LTE coverage in Cell_DCH/Cell_FACH:

Time from call end to TAU Accept: ~19 seconds
SIB19 is always broadcast. The UE may not always read it, since it can read once and remember and read
again only if change is indicated.
In URA_PCH SIB19 change is indicated by Paging. In Cell_FACH and Cell_DCH change is indicated by Sys Info
Change.
In a effort to reduce UEs T-Reselection period, 2nd LTE frequency channel - eARFCN (2175) is removed from
3G UTRAN as recent parameter modification. This change has been provided in BaWa and PHX markets. 2nd
eARFCN is shown as RED in previous page.
RNC/SGSN Resource Release with Connected Core after Reselection to LTE in next page. (Connected Mode
MME and SGSN has a connection to exchange UE context; Non-Connected Mode MME gets UE context from
HSS, not from SGSN)
4G->3G IRAT failure due to RAU Reject & findings

During PHX LTE RF Optimization, RF team reported many 4G->3G Routing Area
Update (RAU) failures, which caused existing call drop in 4G and re-establish new
call in 3G (PDP Context Attach).
The RAU request is initiated from UE as NAS message: RrcInitDirTransf, RNC only pass it
transparently onto SGSN and made no change to its content. SGSN replied to UE via RNC
RANAP either 'RAUpdateAccept or 'RAUpdateReject, then RNC sends it back to UE via DLDCCH. If every thing run properly, then normal RAU procedure should be working as follows
for 4G UE:
RrcInitDirTransf
RrcUL-DCCH
(MessageType => 'RAUpdateRequest',)
RanapInitUeMsg
Ranap
(MessageType => 'RAUpdateRequest',)
RanapDirTransf
Ranap
(MessageType => 'RAUpdateAccept',)
RrcDlDirTransf
RrcDL-DCCH
(MessageType => 'RAUpdateAccept',)
RrcUlDirTransf RrcUL-DCCH
(MessageType => 'RAUpdateComplete',)
RanapDirTransfRanap
(MessageType => 'RAUpdateComplete',)

From LTE markets, the reported failures from logs shown 4 different flavors:
(a) protocol error, unspecified (RAU request and Service request collision)
(b) unanswered RAU (two Santa Clara MMEs having incorrect DNS translations)
(c) roaming not allowed in this location area
(d) GPRS services not allowed in this PLMN
The (a) and (b) have been fixed by SGSN vendor (NSN) & AT&T. (c) and (d) are still under
investigation. Based upon latest join multi-vendor troubleshoot, it appears that either UE SIM is
not registered with GPRS service or, SGSN RAC number is set incorrectly. NSN/SGSN is expected
to provide a readout to those 2 failures.
With fixes from SGSN, PHX RAU test verification has shown a significant improvement and AT&T
is happy with current RAU result, as shown in next page.
SuperCluster1
SuperCluster2
SuperCluster3
Before DNS Fix

Total IRAT Attempts/Failures
58 / 51
32 / 29
50 / 49
After DNS Fix

Total IRAT Attempts/Failures
57 / 2
43 / 1
37 / 2
Samsung UE device plus Ericsson SGSN bug uncovered

In St. Louis market, Samsung 4G UE encountered 2G->3G RAU failure. As described
early, this could create similar problem for existing call to drop once it move from
one technology (GSM/LTE) to other (UMTS). With Redmond Lab extensive
verification tests provided by TIS team and AT&T LTE, it found that the problem was
on Samsung UEs setting of DTM = 1. ATT requirement is that DTM has to be
turned OFF (DTM Enhancements Capability = 0) in RAU message.
Ericsson SGSN accepted HTC UE when ALU RNC passed RAU to it, but no response to
Samsungs. With both UEs logs, it found that HTC has set DTM=0. Therefore, E///
SGSN has been investigated for this potential bug.
Recently, Ericsson has denied its fault and raised question to ALU RNC passed a
wrong length of RANAP message (> 130 Octets) to its SGSN SS7 Stack. AR 1-3554138
has been raised for this investigation.
In Redmond verification test, the following config were used:

Configuration:
4G UE: Samsung I727UCKI4

3G UE: QCT 6290
ALU RNC2 UA7.1.3.6 EP6 TAPB
E/// SGSN4 (IUPS-IP)
2G configuration: E/// BTS and NSN BTS
Test scenario:
UE in idle state
Cell Reselection IRAT 2G/3G both directions
Test results:
4G UE with 4G SIM:
RAU request sent to SGSN
No RAU response from SGSN (see attached Tektronix GeoProb IuPS log)
4G UE with 3G SIM:
RAU Request sent to SGSN
SGSN sent RAU response back to UE
3G UE with 4G SIM:
RAU request sent to SGSN
3G UE with 3G SIM:
RAU Request sent to SGSN

1. All UE logs tested with NSN SGSN and Ericsson SGSN were saved in IH
~umtslogs server:
/home/umtslogs/public_html/umtsutranlogs/9370-LOGS/v713_FFA/LTE/Redmond/
2. All LTE related issues RNC logs are saved in IH ~umtslogs server as
distinguished by market name:
/home/umtslogs/public_html/umtsutranlogs/9370-LOGS/v713_FFA/
drwxrwxr-x 2 fangwx umtscc
10 Sep 24 11:56 Redmond
19 Oct 13 16:07 Phx
7 Oct 17 14:39 Kansas
36 Oct 19 14:39 BaWa
4G UE shown %time spent on LTE is less than expected

One of major issue in LTE launch is percentage of time spent on LTE is less
expected. This issue investigation is still on-going, and it is a join troubleshoot
efforts by: AT&T, HTC, and ALU.
The issue observed is that once 4G UE IRAT to 3G, it will stay on 3G even 4G signal
is better and Cell-Reselection conditions are met. From RNC callTrace logs, UE
does not move to FACH or slowly move to FACH, all of these accounted for time
which UE spent on 3G. That brought an important questions:
1. if UMTS RAN hold UE to prevent it from Cell-Reselection back to LTE?
2. If any 3G design and parameters properly set during UE IRAT to 3G?
3. Is UEs application (Hasati test suite for HTC Waikiki) worked correctly to engage 3G>4G Cell-Reselection? (Both HTC and Samsung using Qualcomm Chip Set)
By far many approaches have been explored, based on a large amount of field logs
and data, it shows that RNC/Nodeb worked as expected on call procedure (setup,
reconfiguration, terminate, etc.) and State transitions. As today, URA_PCH is not
activated in GA RNCs yet, so only avenue to LTE is via cell-reselect in Idle state.

The latest update on Launched LTE market BaWa shown a promising progress on
finding why 4G UE stuck on UMTS After IRAT from 4G to 3G. Both Hasati application
and AT&T Stream application (Android based app developed by ATT) are used in this
debug:
UL(EDCH) data transfer was stalled or delayed to TCPIP server when MO call setup
on 4G and IRATed to 3G, which caused by upstream network (eg PGW) or application
server blocking or delay, main signature is a Syn msg is sent but the Syn Ack is never
received from the server. Once call blind IRAT to 3G due to RF condition, this
problem got more obvious, and its UL data rate observed as less than 64kbs. For a
4M file to send or stream data, once UL stall or delay, it took a much longer time to
complete transfer in 3G before move UE to FACH, then Idle.
With LTE parameter pdcpDiscardTimer changed from 1500 ms to infinity, it helps
some degree, but it does not solve the issues. At present investigation, there 8
scenarios found during this troubleshoot, they are shown in next page.
Coming action plan from ALU BaWa team:

Meetings continue with HTC and ATT, run by ATT incubation team. For ALU our key next steps
Validate TAU reject cases is known scenario and provide team details of fi
Support additional testing to troubleshoot the No Syn Ack case. Server, PGW logs to be collected to
isolate problem.
Complete some targeted analysis of failures and finalize report
Refocus discussion on the original scenario with Large packet drops. Will work with both HTC and ATT
on this.

Attached are some view graphs and email from BaWa markets. For Pre-commerical
AT&T market Kansas, where Ericsson SGSN is in service for ALU RNC, the %time on
LTE is in similar number as BaWa. The Drive test result from KC RF drive team is
attached.
Update on 3-way
effort (ALU ATT HTC) on
LTE Param
Chgs _101811_v2.xls x
ATTpres ent
10_10v2.pdf
LTE_UMTS_Kans as _
10122011.ppt
3G & 4G share same transport layer: SIAD(7705) and MSN(7750)

ALU provided a common backhaul platform to both 3G and 4G in BaWa: 7750 and
7705. This solution has been FFAed in the mid-2011 (May &June). The UMTS Site
DL Power spike has been observed from field deployment of SIAD and MSN sharing
UL data transport channel for a given QoS profile.
MSN provisioned a Shared UL QoS Policy to both 3G and 4G Nodebs, which are colocated in geo-vicinity. Both 3G and 4G use this provisioned channel for UL data
transfer. As todays EDCH higher demand, 3G service has already fully used of UL
BW, so it can not simply use a shard mechanism to provide both technologies
service properly. Here are concerns from UMTS side:
when UMTS Nodeb and LTE eNodeb shared same SIAD and using same QoS Policy/EVC, how
we expect Bandwidth be divided by each technology ? According to Bill M., the current
design is First Come First Serve, then one or other could face resources exhaust if
sharing mechanism is deployed. Bill M also mentioned that there is Alternative QoS Policy:
can mitigate the issue. Can we try this when LTE starting test on those Nodebs ?
For 40M QoS Link Profile, if it matches to minimum RNC/Nodeb PM measurement 15

minute granularity? Since instantaneous IuB BW usage peak can top 40M QoS Policy, is it
relied on QoS Policy to strip off DL/UL data packet from SIAD or MSN when it exceed? When
this happen, UMTS call setup or existing call could be failed. UE will retry and it may cause
of DL power increase. Thus correct link profile provisioned for a nodeb is important from
mobile backhaul.

The data from RNC PMV shown for a given Nodeb: MDU2292 had 284 failures on DL Power. Form
IuB activity of both Uplink and Downlink, this duration shown IuB BW usage as below:
MDU2292 14:15 14:30:
UpLink IuB usage (ulIubAct): 30.65 M
DownLink IuB usage (dlIubAct): 26.55 M
The UL IuB usage is provided by the following counters from a RNC PM file, the sum of all
counters values for a given time interval (e.g. 15-minute) shown a total usage of IuB in a
nodeb:
VS.DedicatedUplinkActivityRlcRefCell.UlRabCsData64
[ CSD ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabCsSpeech [ CSV ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabCsStr [ CSSTR ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabHsupa [ HSUPA ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabOther [ Other ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabPsIb128 [ IB128 ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabPsIb16 [ IB 16 ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabPsIb384 [ IB384 ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabPsStr16 [ ST16 ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabPsStr64 [ ST64 ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabPsStrHsupa [ ST_HS ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabPsStrOther [ STOth ]
VS.DedicatedUplinkActivityRlcRefCell.UlRabSRB [ SRB ]

The solution to the problem is to use Alternate QoS Policy in UL for 3G and 4G
Nodebs in same location. After change, the transport were declared good. RNC
/Nodeb DL Power spike eliminated.
According to Bill MacLeod, AT&T is proceeding to incorporate, what they call,
revised QoS implementation in next year. It will include LA4.0 eNodeB UL shaping,
changes to SIAD/MSN and possible changes to NodeB DSCP markings.
Attached are documents for IuB/IP network diagram and its link profile started from
v7.1.1.x in AT&T market ALU OneBTS Nodebs. Also presentation from Bill MacLeod,
IPD team about Mobile Backhaul change.
Iub over IP Link

Profiles for UA7.1.1.8
UA07_IuB_IP_FFA_
diagram.ppt
ATT IP (SIAD MSN)

Mobile Backhaul DA v0.
Recommendation to RF drive test preparation

To make efficient of RF drive work and effort, the following are recommendation to
preparations:
UE Name & Model, IMSI number(s), SIM card version(s), FW versions, UE device provisioning
Mode (APN, DV, DO, etc.);
UE power cycle right before test, and test equipment seen right display (Freq, EcNo/RSRP,
RSCP, power, etc.)
Drive route with 3G Nodeb list (RNCs) and 4G eNodeb list;
Test scenario(s) were properly designed to create or re-produce the problem;
The time of day issue most occurred and test duration to get to problem.
After Drive test, it will be help to have Drive team provide:

1. UE logs (QXDM) along Drive route;
2. UE(s) Drive test scenarios with time stamp, e.g. CS/PS or both, FTP, Ping, UL/DL file,
MO/MT, etc.
3. RF drive route plot on success or failure Cell-Reselection and its RF condition, as well as
UE is on LTE or UMTS.
RNC logs, traces, tools to analyze issues

RNC logs analysis for current issues are mostly used in IMSI trace logs, and
Geoprobe/WireShark trace logs.
The tools are:
eDAT: for both UE and RNC logs (esp. for Cell trace)
QCAT: QXDM logs decoder and converter for UE logs
CTA: Call Trace Analyzer for RNC CTb(IMSI)/CTg logs
RFO: RF Optimization Analyzer for both RNC and UE logs.
WireShark: for RNC <-> CN, or IuB/IuR/IuCS/IuPS over IP tarcing logs.
RNC GPS has suggested a callTrace template (GPSCOMBO7_CTb_UPOS09) for CellReselection, this template is to collect RNC logs: tmu, upos, ppc additional to IMSI
trace.
Attached are upos config TMU.upos.CTact9 (TMU.upos.CTact9_AddInternal1CellRRM.txt) and official upos config
of v7133 EP6 GA load. For coming RNC Drive test, if tmu, upos, or other logs may be required, please update
upos config to v7133 EP6 before starting.
RI713053B2831.zip
Back Up

RRC INTERFACE MANAGEMENT
When modifications of system information blocks, upon Cell Resource Managements request,
RRC Interface Management informs the mobiles in idle mode, in URA_PCH and CELL_PCH RRC
states, or in CELL_FACH RRC state to read a SIB again. It notifies the new MIB_value_tag in the
IE "BCCH modification info", transmitted in the following way:
UEs in idle mode, in URA_PCH or CELL_PCH RRC states, the IE "BCCH modification info" is
contained in a PAGING TYPE 1 message transmitted on the PCCH in all paging occasions in the
cell.
UEs in CELL_FACH state, the IE "BCCH modification info" is contained in a SYSTEM
INFORMATION CHANGE INDICATION message transmitted on the BCCH mapped on at least one
FACH on every S-CCPCH in the cell.
Note: mobiles in Cell_DCH state do not need to be informed of the System Information
modification and will see this modification when leaving Cell_DCH. The above functions already
exist and are not supposed to be changed. This feature does not impact RRC Interface
Management function.

CALL MANAGEMENT
Call Management function handles call resource release for those UEs in CELL_PCH or URA_PCH
which already made cell reselection to LTE. Upon RANAP Iu Release Command, RNC releases
resources for the concerned UE. RNC sends RRC Paging Type1 to UE for the release. See [R9].
For Rel-7+ UE, if PM90009 is activated (ServiceInit->isDirectTransitionFromPchToIdleAllowed ==
TRUE), in Paging Type1 message the IE RRC Connection Release information is set to
Release, UE will release all its resources directly. RNC is not expecting any response from UE
in this case (see [R10]). Otherwise, UE will move to CELL_FACH first before release the
resources.
As Assumption 2 stated, for CELL_PCH/URA_PCH mode cell reselection to LTE, RNC relies on
Core Network SGSN Iu Release Request to release resources. The value of the IE cause
contained in the Ranap IU Release Command message is not defined in 3GPP and so is SGSN
implementation dependent. Since the RANAP Release cause is not accurate, the RNC cannot
optimize the resources release. So it has to apply the same procedure as the UE remains
attached to the RNC: it sends a Paging Type 1. In case of no UE answer it releases its internal
resources. It is also not possible to count PCH mode UE cell reselection towards LTE. These are
existing functions. This feature does not impact Call Management function.

CELL RESOURCE MANAGEMENT
Cell Resource Management triggers System Information Update procedures during cell
initial setup or unlock, or when System Information configuration is modified. The cell setup
(or unlock) sequence before the transmission of System Information Blocks to the relevant
FDD cell is not modified and only the contents of these blocks is modified with the optional
addition of System Information Block type 19.
Cell Resource Management has three major functions, with regard to the new SIB19:
1. Configuration management: manages SIB19 configuration parameters received from
OMC-R/MIB during loadDP or online TEA set, and stores them into RNC internal
context
2. Build SIB19: Parameters filling, encoding, and transport block segmentation if needed.
3. Dynamic SIB scheduling
Cell Resource Management also notifies UEs in the cell the System Information change.

3g 4g InterworkingSupport

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3g 4g InterworkingSupport

Uploaded by

Copyright:

Available Formats

ALU UTRAN GPS Support to AT&T 3G->4G

Inter-working for LTE Launch

ALU UTRAN GPS

3G-4G Inter-working Markets & issues

3G supporting AT&T 4G commercial launch is a broad topics. With a limited

2 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

V7.1.3 RNC releases introduced LTE Cell-Reselection to support LTE

3 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

UMTS SIB19 configuration

4 | ALU 3G -> 4G Interworking Support | Oct 2011

TS 25.304, 25.133, 25.331, 23.401

UMTS Sib19 was introduced in3GPP TS 25.331 v8.4.0.

Cell Reselection between UMTS & LTE is based on

Applicable to FDD serving & LTE Frequencies

Eligible in UE Idle, URA_PCH & CELL_PCH Modes

Bidirectional reselection in Idle Mode

Unidirectional reselection for URA_PCH &

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

5 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

6 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

As Threshx,High and Treselection are key parameters to Cell-Reselection, ATT

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

RNC/Nodeb/FDDCell/reserved4,5,6,7. (detail encoding is in previous attachment, or ALU UPUG)

9 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

10 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

SIB19 broadcast every 640ms nominally as defined in SchedulingInfo

SIB19 repetition will be no slower than 2560ms

UMTS to LTE Reselection possible in Idle and URA_PCH, not in Cell_FACH

SIB19 change indicated to a UE in Cell_FACH with Sys Info Change

Driving from UMTS only to UMTS+LTE coverage in Idle mode:

Driving from UMTS only to UMTS+LTE coverage in Cell_DCH/Cell_FACH:

12 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

Mobility between UMTS and LTE Cell Reselection

13 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

4G->3G IRAT failure due to RAU Reject & findings

(MessageType => 'RAUpdateRequest',)

(MessageType => 'RAUpdateRequest',)

(MessageType => 'RAUpdateAccept',)

(MessageType => 'RAUpdateAccept',)

(MessageType => 'RAUpdateComplete',)

(MessageType => 'RAUpdateComplete',)

14 | ALU 3G -> 4G Interworking Support | Oct 2011

All Rights Reserved Alcatel-Lucent 2011

4G->3G IRAT failure due to RAU Reject & findings