3G Smartphones Impact

Smartphones Impact on 3G Radio Network Feature for smartphone in NSN 3G Radio Networks

Smarphone’s Concept Introduciton & General Smartphone Information

4 © Nokia Siemens Networks

For internal use

Introduction New ”smart” applications

• Very popular in many networks starting to be ”Always on” applications such as: ▪ instant messaging,

▪ push email,

▪ location services,

▪ weather widgets etc.

• The new Smartphones such as G1, iPhone and N97 are supporting ”Always on” application

• ”Always on” applications rely on ”Keep Alive” messages, which are send freqently to keep connectivity for a good service experience.

• ”Keep Alive” messages loading the network in a new way


For internal use

Introduction Smart Application Typical Behavior

• Always-on applications need to send and receive small packets very frequently to keep IP connectivity open (“Keep Alive” messages)

• Always-on traffic is charecterozed by rapid connections with relatively small amount of data exchanged

• Battery duration is the first priority therefore

• The Smartphones optimize their battery life time by forcing the terminal to IDLE mode after the Keep Alive message is sent.

Cell_PCH/IDLE

Cell_DCH

Keep Alive

message

Standard

message


For internal use

Introduction to ”smart” problems Effects of always-on applications

• Multiple applications run on top of each other with independent heartbeats

• This causes lot of IDLE mode to dedicated mode state changes, for which the terminal has to go through the full process of connecting to the Core network again

• Smartphone applications are increasing Control Plane load compared to the typical and more widespread CS, PS and HSPA services used until now

• C-Plane to U-Plane traffic ratio is increased

~ x-seconds

Traffic

Different applications may have

Keep Alive messaging with different

frequency and size


For internal use

General concept

Application is a single entity which:

is not associated with a subscriber in the 1:1 relation

single subscriber can have more than one application running independently from each other

not every subscriber that posess Smartphone has to have active application

is installed on a mobile phone*

works 24/7/365 – always online

transmits data without user’s activity – Keep Alive

generates traffic based on certain pattern

* Application installed on PC connected to the mobile network not included, under assumption that user generates additional traffic and has reserved resources during whole session

Smartphone

mobile phone with capability to use different applications


For internal use

Smartphones applications traffic types

• Smartphones applications are generating two types of traffic

– User activity messages

▪ In general this messages portions (>2kB) are too big to fit on common control channels

▪ This traffic value is currently included in the Traffic Model figures

▪ Due to lack of Smartphones counters there was no possibility to distinguish it from current services

▪ If there is a need to create service that reflects this traffic type please refer to recommendation for further slides

– Keep Alive messages

▪ Very small amounts of data (~150B) that are send by terminal periodical, without any user interaction

▪ Usually if the network is configured in a good manner, transmission of this data is done on common channels


For internal use

Smartphones applications traffic types

Outgoing User Activity Message


Incoming User Activity Message

Keep Alive Message

Keep Alive Message

Keep Alive Message

Keep Alive Message

Keep Alive Message

Keep Alive Message


Incoming User Activity Message

Keep Alive Message

• regular appearance

• messages are being send in

equal time distances

User activity messages

• irregular appearance

• send time distances averaged

over BH

• Two messages type:

•Incoming

•Outgoing


For internal use

Parameters describing the Smartphone behaviour

Keep Alive messages related parameters

• Keep Alive message size – number of bytes to be transferred on air interface

• Cell_FACH to Cell_DCH trigger – maximal amount of data that can be send on control channels

• Time between Keep Alive messages

• Amount of RRC messages send prior to Keep Alive message – parameter influence final signalling load result

• RACH payload – 360 (user data), 168(RRC signaling)

• RACH_TTI – 10 ms (10), 20 ms (20)

User activity messages related parameters

• Message size – is a number of bytes that need to be transferred on air interface to send user message via application. Parameter with combination of DCH bearer type impacts message transaction time

• Time between messages – describes how often messages are send. This impact total BH user data volume of Smartphone traffic

• Network inactivity timers – time during which the dedicated resources reserved after message transmission finish (T1 timer, described further)


For internal use

Parameters describing the Smartphone behaviour Network parameters - Cell_FACH to Cell_DCH trigger

Traffic Volume Measurement low threshold

UL This parameter defines, in bytes, the threshold of data in the RLC buffers of SRB0, SRB1, SRB2,

SRB3, SRB4 and all NRT RBs that triggers the uplink traffic volume measurement report, when the

UE is in Cell_FACH state.

Otherwise, UE sends data on RACH.

DL This parameter defines, in bytes, the threshold of data in the RLC buffers of SRB3, SRB4 and all NRT

RBs that triggers the downlink traffic volume measurement report (capacity request) on MAC, when

UE is in Cell_FACH state.

Otherwise, RNC sends data on FACH.

Allowable

values

8 bytes (8), 16 bytes (16), 32 bytes (32), 64 bytes (64), 128 bytes (128), 256 bytes (256), 512 bytes

(512), 1 KB (1024)

Default value 128 bytes

Base on this parameter settings decision is taken whenever send

particular message on DCH or on Control Channels


For internal use

Smartphone global penetration

0

1

2

3

4

7

2008 2009 2010 2011 2012 2013 2014

Mobile subscriptions, smartphone installed base, and

Smartphone percentage of subscriptions

Source: Pyramid Research, June 2010

Mo

bile s

ub

cri

pti

on

s (

billio

ns)

Non-smartphones

Smartphones

Perc

en

tag

e o

f su

bscrip

tion

s

5

6

0

4%

8%

12%

16%

28%

20%

24%

Smartphone application penetration

is 12% to 13% for 2011


For internal use

Calculations assumptions Number of Smart Applications

rs#Subscribe

tionon_penetra_applicatiSmartphonelications#Smart_App

Subscribers have

assigned RU30 traffic

model services split

Maximal amount of RU30 subscribers is determined base maximal

capacity of 3 sector site with one carrier and 50% of load.

413 subscribers

per cell

1239 subscribers

per BTS

(with one carrier)

1239 subscribers

per IuB

799155

subscribers per

RNC

(RNC2600/3 with

645 BTSs)

Smartphone’s Concept Part 1 – Smartphone traffic network impact


For internal use

Smartphone’s Concept Introduction

Smartphone’s affect network load in two ways:

• User activity messages

• Air interface load

• Spreading Code tree occupation

• Baseband resources occupation

• Keep Alive messages

• Air interface load

• Spreading Code tree occupation

• Baseband resources occupation

• PRACH load

• SCCPCH load

User activity messages in Cell_DCH state Impact on air interface load


For internal use

User activity messages in Cell_DCH state Impact on air interface load (1)

Smartphone applications generate traffic which affects the air interface load. This impact can be estimated base on user activity messages related parameters.

First step of presented method will be calculation of number of Smartphone applications active in Busy Hour as it is mandatory input for the whole calculation procedure.

• Number of Smartphone applications (#SP_applications) active in Busy Hour in the network

where:

#Subscribers – number of subscribers in the investigated network

SP_applications_penetration [%] – percentage of subscribers using Smartphone applications

npenetrationsapplicatioSPsSubscribernsapplicatioSP __#_#


For internal use


Each Smartphone application is characterized by number of incoming and outgoing user messages. It means that Smartphone application not only receives but also sends messages.

Number of incoming and outgoing user messages can be calculated base on formulas shown below.

• Number of incoming user messages received in Busy Hour (#In_messages)

where:

Tum1→um2 [s] – time between subsequent user messages

Percentage_in_messages [%] – percentage of incoming messages, which reflects ratio between incoming and all (incoming and outgoing) messages

messagesinPercantageT

smessagesIn

umum

__3600

_#21


For internal use


Smartphone applications cause load on the air interface only if transmission is performed on DCH channel. It means that size of user message has to be higher than Downlink / Uplink traffic volume measurement low threshold, otherwise transmission will be performed on CCCH channel (FACH).

If mentioned condition is fulfilled, data volume generated by each incoming and outgoing user message can be obtained using formulas presented below and on the next slide.

• Incoming user message

– Data volume related to single incoming user message in UL (UL_in_message_vol [kbit])

where

ACK_NACK_size [bit] – size of confirmation message (default value is 360 bits)

1000

_____

sizeNACKACKvolmessageinUL


For internal use


Using previously obtained data volume for each single message, number of messages sent in Busy Hour and number of Smartphone applications, data volume per whole investigated area can be calculated with formulas presented below.

• Data volume transmitted per area in UL (UL_data_vol [kbit])

• Data volume transmitted per area in DL (DL_data_vol [kbit])

Obtained figures reflect data volume generated by all Smartphone subscribers in the network in each transmission link.

nsapplicatioSPvolmessageoutULmessagesOutvolmessageinULmessagesInvoldataUL _#____#____#__

nsapplicatioSPvolmessageoutDLmessagesOutvolmessageinDLmessagesInvoldataDL _#____#____#__


For internal use


To estimate how Smartphones traffic influence the cell load, capacity demand for every single cell in the network has to be calculated using following formulas.

• Capacity demand in UL (UL_cap_demand [kbps])

• Capacity demand in DL (DL_cap_demand [kbps])

where:

#Sites – number of sites in the network

#Sectors – number of sectors per site (site layout)

#Carriers – number of carriers per site

sCarriersSectorsSites

voldataULdemandcapUL

3600###

____

sCarriersSectorsSites

voldataDLdemandcapDL

3600###

____


For internal use


Base on previously calculated capacity demand, UL and DL cell load for certain bearer can be calculated. It is recommended to use PS 16kbps I/B as a reference bearer to reflect the behavior of Smartphone applications.

• Cell load generated by Smartphones in UL (UL_cell_load [%])

• Cell load generated by Smartphones in DL (DL_cell_load [%])

where:

UL_spectral_eff [kb/s/cell/MHz] – UL spectral efficiency

DL_spectral_eff [kb/s/cell/MHz] – DL spectral efficiency

MHzeffspectralUL

demandcapULloadcellUL

5__

____

MHzeffspectralDL

demandcapDLloadcellDL

5__

____

User activity messages in Cell_DCH state Impact on Spreading Code tree occupation


For internal use

User activity messages in Cell_DCH state Impact on Spreading Code tree occupation (1)

Occupation of Spreading Code tree is affected by Smartphones traffic only in case when transmission is performed on R99 dedicated channel (DCH). This happens only if size of user message is higher than Downlink / Uplink traffic volume measurement low threshold, otherwise transmission is performed on CCCH channel (FACH).

Each bearer established in DL consumes part of available Spreading Code tree resources (correspondent Spreading Factor is assigned for transmission). From Smartphones perspective, Spreading Codes resources will be reserved for incoming and outgoing user messages as well. This comes from the fact that for every single connection two bearers are established – UL and DL RAB (Radio Access Bearer).

When outgoing user message is being sent in UL, DL bearer is sustained even though there is no transmission. This is the reason why it has no impact on the air interface load but it always has to be considered in Spreading Code tree occupation – SF is always occupied by this bearer.


For internal use


Timer T1 (InactivityTimerDownlinkDCH and InactivityTimerUplinkDCH) indicates how long the radio and transmission resources are reserved after silence detection on UL/DL DCH before release procedures. Timer T1 is defined separately for each bit rate and transmission direction.

For PS 16kbps I/B bearer default value for UL and DL is 5 seconds.

Inactivity timer T1 has impact on Cell_DCH occupation from Spreading Codes perspective only while from air interface load perspective it has no impact (there is no transmission during inactivity timer T1).


For internal use


The total Spreading Code occupation time in Busy Hour for each cell in the network can be calculated base on previously shown user plane and control plane related parameters.

• Total user plane Spreading Code occupation time for one cell in Busy Hour (Total_user_plane_TSC [h])

where:

Soft_HF – Soft Handover Factor

Softer_HF – Softer Handover Factor

Default values of Soft_HF and Softer_HF parameters are respectively 1,3 and 1,08.

10003600###

___#_#____#______

CarriersSectorsSites

HFSofterHFSoftnsapplicatioSPmessagesOutTplaneuserOutmessagesInTplaneuserInTplaneuserTotal SCSC

SC


For internal use


• Total control plane Spreading Code occupation time for one cell in Busy Hour (Total_control_plane_TSC [h])

If result of these two equations will be in any case higher than 1 hour it means that more than one Spreading Code has to be reserved in Busy Hour.

Finally the Spreading Code tree occupation can be calculated with the following formula.

• Spreading Code tree occupation (SC_occupation [%])

where: DL_SF – Spreading Factor of DL bearer

SRB_SF – Spreading Factor of SRB

10003600###

___#_#____#______

CarriersSectorsSites

HFSofterHFSoftnsapplicatioSPmessagesOutTplanecontrolOutmessagesInTplanecontrolInTplanecontrolTotal SCSC

SC

SFSRB

TplanecontrolTotal

SFDL

TplaneuserTotaloccupationSC SCSC

_

___

_

____

User activity messages in Cell_DCH state Impact on Baseband occupation


For internal use

User activity messages in Cell_DCH state Impact on Baseband occupation(1)

Occupation of Baseband resources is affected by Smartphones traffic only in case when transmission is performed on R99 dedicated channel (DCH). This happens only if size of user message is higher than Downlink / Uplink traffic volume measurement low threshold, otherwise transmission is performed on CCCH channels (RACH/FACH)

Each R99 DCH bearer (UL/DL) consumes certain amount of CE for traffic data processing. Required number of CE depends on the bearer rate. Allocated CE resources provides R99 data processing but also covers Signaling Radio Bearer (SRB) processing (when DCH is established additional resources for SRB are not needed)


For internal use


• Baseband allocation time caused by control plane related to single incoming user message (In_control_plane_TBB [ms])

where

Setup_time [s] – call setup time in Cell_FACH state related to SRB (time between RRC_CONNECTION_SETUP and RADIO_BEARER_SETUP_COMPLETE)

Default value of Setup_time parameter is 2,8 seconds.

1000_______ timeSetupTplaneuserInTplanecontrolIn BBBB


For internal use


The total time of Baseband resources allocation in Busy Hour for each site in the network can be calculated base on previously shown user plane and control plane related parameters.

• Total user plane Baseband allocation time for one site in Busy Hour (Total_user_plane_TBB [h])

where:

Soft_HF – Soft Handover Factor

Default values of Soft_HF parameter = 1,3

10003600#

__#_#____#______

Sites

HFSoftnsapplicatioSPmessagesOutTplaneuserOutmessagesInTplaneuserInTplaneuserTotal BBBB

BB

Keep Alive messages in Cell_DCH state Impact on air interface load


For internal use

Keep Alive messages in Cell_DCH state Impact on air interface load (1)

For each Keep Alive message:

• data is sent in UL

• ACK / NACK is received in DL (acknowledgement information on delivery of Keep Alive message)

Confirmation messages (ACK / NACK) are triggered by each Keep Alive message and sent in DL that is why they have to be considered in dimensioning process.

Data volume generated by each Keep Alive message can be obtained using formulas presented on the next slides.


For internal use


• Data volume related to single Keep Alive message in UL (UL_keep_alive_vol [kbit])

where

Keep_alive_size [bit] – size of single Keep Alive message (default value is 150 Bytes)

• Data volume related to single Keep Alive message in DL (DL_keep_alive_vol [kbit])

Data volume per whole investigated area including traffic generated by Keep Alive messages sent on DCH channel can be calculated with formulas presented below.

1000

_____

sizeNACKACKvolalivekeepDL

81000

_____

sizealiveKeepvolalivekeepUL


For internal use


• Data volume transmitted per area in UL (UL_data_vol [kbit])

• Data volume transmitted per area in DL (DL_data_vol [kbit])

For cell load calculation please refer to User activity messages in Cell_DCH state section as the further calculation steps are the same for both type of messages.

nsapplicatioSPvolalivekeepDLmessagesaliveKeep

volmessageoutDLmessagesOutvolmessageinDLmessagesInvoldataDL _#

_____#

____#____#__

nsapplicatioSPvolalivekeepULmessagesaliveKeep

volmessageoutULmessagesOutvolmessageinULmessagesInvoldataUL _#

_____#

____#____#__

Keep Alive messages in Cell_DCH state Impact on Spreading Code tree occupation


For internal use

Keep Alive messages in Cell_DCH state Impact on Spreading Code tree occupation

Keep Alive messages periodically sent by Smartphone applications may affect also the Spreading Code tree occupation. If size of Keep Alive message is higher than Downlink / Uplink traffic volume measurement low threshold transmission is performed on DCH channel. In this case traffic generated by Keep Alive messages has to be taken into account during spreading code tree occupation

Calculation approach for Keep Alive messages is the same as for user activity messages. First step in this method is calculation of user and control plane Spreading Code occupation time related to single Keep Alive message.

• User plane Spreading Code occupation time related to single Keep Alive message (Keep_alive_user_plane_TSC [ms])

1000__

_______ 1

T

throughputbearerDL

volalivekeepDLTplaneuseraliveKeep SC

User and Keep Alive messages in Cell_FACH state Impact on Common Control Channels load

(PRACH and SCCPCH)


For internal use

Impact of Keep Alive messages on Common Channels

Keep Alive messages transfer is done via common channels and impacts:

• PRACH load (RACH)

• S-CCPCH load (FACH & PCH)

If the network setting related to Cell_FACH to Cell_DCH trigger is set to too low value each Keep Alive message will be transferred using Cell_DCH state

• traffic volume measurement low threshold parameter is set to value lower than Keep Alive message size

• In this case Keep Alive messages – shall be dimensioned according to method for user activity data

– shall generate only single message on:

▪ RACH RRC_CONNECTION_REQUEST

▪ FACH RRC_CONNECTION_SETUP


For internal use

User Plane Data

Needed at first keep

alive message only

RRC_CONNECTION_REQUEST (1 TB)

Keep Alive message – Signalling Flow

RRC_CONNECTION_SETUP (3 TB)

INITIAL_DIRECT_TRANSFER (1 TB)- CM SERVICE REQUEST

RRC_CONNECTION_SETUP_COMPLETE (2 TB)

DOWNLINK_DIRECT_TRANSFER (2 TB)

AUTHENTICATION AND CIPHERING REQUEST

UPLINK_DIRECT_TRANSFER (1 TB)

AUTHENTICATION AND CIPHERING RESPONSE

UPLINK_DIRECT_TRANSFER (5 TB)

ACTIVATE_PDP_CONTEXT_REQUEST


ACTIVATE PDP CONTEXT ACCEPT

UPLINK_DIRECT_TRANSFER (? TB)


RRC_CONNECTION_RELEASE (1TB)

RRC CONNECTION_RELEASE_COMPLETE (1 TB)

Control Plane

6 RACH TBs

User Plane

? RACH TBs

(Keep Alive Message

Size dependant)

Only these messages are send using

common channels if network setting

related to Cell_FACH to Cell_DCH

trigger is set to too low value

Control Plane

7 FACH TBs

User Plane

1 FACH TBs

Not Send on CCCH

Cel

l_F

AC

H

Idle

Id

le

SECURITY_MODE_COMMAND ( 2 TB)

SECURITY_MODE_COMPLETE (1 TB)

MEASUREMENT_CONTROL ( 1 TB)

SIGNALING _CONNECTION_RELEASE_INDICATION (1 TB)


For internal use

Impact of User Activity Message on Common Channels

RRC_CONNECTION_REQUEST (1 TB)

RRC_CONNECTION_SETUP (6 TB)

INITIAL_DIRECT_TRANSFER (1 TB)

CM SERVICE REQUEST

RRC_CONNECTION_SETUP_COMPLETE (2 TB)

PAGING TYPE1 (1 TB) Related to incoming messages

Only single control plane message is

required to initiate User Activity

Message Transmission 1 RACH TB

Further signaling done

on SRB over DCH

To initiate User Activity Message

Transmission in case of

Incoming Message

Two control plane messages required

6 FACH-c TBs + 1 PCH TB

Outgoing Message

One control plane message required

6 FACH-c TBs

Cel

l_D

CH

Id

le


For internal use

PRACH - channel parameters

TTI TBS Plane Type Data RateChannel

Types

10 ms 16,80 kbps

20 ms 8,40 kbps

10 ms 36,00 kbps

20 ms 18,00 kbpsDTCH

DCCH or

CCCH168 bits

360 bits

Control

User

Max Keep Alive

Message Size

#RACH

Messages

45 Bytes 1

90 Bytes 2

135 Bytes 3

180 Bytes 4

225 Bytes 5

270 Bytes 6

315 Bytes 7

For most common Keep Alive Message

size ~150Bytes there is a need

for 4 RACH TTIs to transmit it

Part 2: Smartphone related features


For internal use

Intoduction Smartphones related features

Studies presented in previous chapter assumed no features in the network that improves Smartphones’ user experience.

This chapter presents impact of those features on Smartphones’ cacluation.

Following features are presented in this chapter:

• Common Channel Setup (RU10 On Top, I-HSPA Rel3)*

• Cell_PCH (before RU10, I-HSPA Rel1)

• High Speed Cell_FACH (RU40, I-HSPA Rel5)*

• Fast Dormancy (RU20, I-HSPA Rel4)*

• Fast Dormancy Profiling (RU40, I-HSPA Rel5)*

• State Transitions Counters (RU40, I-HSPA Rel5)*

*Software releases according to March 2011 Roadmap

Smartphone related features RAN1797 Common Channel Setup


For internal use

Common Channel Setup Impact on Smartphone dimensioning method

Feature impacts:

• User activity messages

– If Cell_PCH is not active (if activated UE is assumed to start form Cell_PCH where RRC connection is already established)

– If in SRBMapRRCSetupEC parameter 3rd and 7th bit is set to 1.

▪ 3rd bit enables feature for Originating background call

▪ 7th bit enables feature for Terminating interactive call

– Additional RRC messages to be send

– However this feature is not going to create common channel congestion, In case of high CCH load RRC will be transmitted on DCH resources

– Impacts on code tree occupation

• Keep Alive messages

– No impact since RRC connection already assumed to be done on CCH.

Feature is intended to save radio interface capacity, and to utilize, instead of DCH 13.6 kbps or DCH 3.4 kbps signalling link,

RACH/FACH common channels for RRC signalling


For internal use

Common Channel Setup Impact on Spreading Code tree occupation (2)

CCCH Setup OFF

CCCH Setup ON

Lower Spreading Code tree occupation due to

shorter occupation time caused by SRB

Smartphone related features RAN1124 Cell_PCH


For internal use

Cell_PCH Impact on network

Cell_PCH availability in the network significantly reduces amount of signalling messages and reduces UE battery consumption.

• Low resources consumption (e.g. UE battery consumption) in Cell_PCH state

• Short Keep Alive messages can be sent over FACH (state transition to Cell_DCH avoided)

• Less paging load (UE is paged in one cell instead of whole Location Area or Routing Area)

• Short state transition time from Cell_PCH to Cell_FACH and Cell_DCH / from Cell_FACH and Cell_DCH to Cell_PCH


For internal use

Cell_PCH Impact on Keep Alive messages (1)

Short and frequent Keep Alive messages can be sent over Cell_FACH (state transition to Cell_DCH avoided)

• During inactivity UE maintained in Cell_PCH (low battery consumption)

• To send short Keep Alive message state transition to Cell_FACH is needed (transition to Cell_DCH not required)

• Due to low number of RACH RRC signalling messages Cell_PCH state implementation allow to significantly reduce RACH load

Cell PCH

Cell FACH

Cell PCH Cell PCH

Cell FACH

Data transfer

Timer

Cell_FACH

Cell_PCH


For internal use

Cell_PCH Impact on Keep Alive messages (2)

CELL_UPDATE (1 TB)

CELL_UPDATE_CONFIRM (1 TB)

UTRAN_MOBILITY_INFORMATION_CONFIRM (1 TB)

User Plane

Data

UPLINK_DIRECT_TRANSFER (? TB)


PHYSICAL_CHANNEL_RECONFIGURATION_COMPLETE (1 TB)

Cel

l_F

AC

H

Cel

l_P

CH

PHYSICAL_CHANNEL_RECONFIGURATION (3 TB)

Cel

l_P

CH

Control Plane

3 RACH TBs

User Plane

? RACH TBs (Keep Alive Message Size dependant)

Control Plane

4 FACH TBs

User Plane

1 FACH TBs

Cell_FACH

Cell_PCH

Exemplary message flow presenting Keep Alive message sent

over Cell_FACH


For internal use

Cell_PCH Impact on User messages (1)

Implementation of Cell_PCH feature allows to reduce time required to reach Cell_DCH state

• During inactivity UE maintained in Cell_PCH (low battery consumption)

• To send User message state transition to Cell_DCH is needed

• State transition to from Cell_PCH to Cell_DCH (via Cell_FACH) requires only ~700ms and therefore consumption of signalling resources require less time (shorter time of Spreading codes and Baseband resources occupation)

Cell_DCH

Cell_FACH

Cell_PCH


For internal use

Cell_PCH Impact on User messages (2)

RADIO_BEARER_RECONFIGURATION (4 TB)

MEASUREMENT_CONTROL (1 TB)

RADIO_BEARER_RECONFIGURATION_COMPLETE (1 TB)

CELL_UPDATE (1 TB)

CELL_UPDATE_CONFIRM (1 TB)

Cel

l_D

CH

C

ell_

FA

CH

C

ell_

PC

H

Control Plane

3 RACH TBs

User Plane

? RACH TBs (Keep Alive Message Size dependant)

Control Plane

5 FACH TBs

User Plane

1 FACH TBs

Cell_DCH

Cell_FACH

Cell_PCH

Exemplary message flow presenting User message sent over

Cell_DCH (starting from Cell_PCH state)


For internal use

Cell_PCH RACH Occupation - Calculation example

Cell_PCH

OFF

RACH RRC

signalling

load

reduction due

to lower

amount of

RRC

messages

needed to

initiate Keep

Alive

transmission

Current slide presents exemplary situation when PCH feature is disabled and

enabled.

Cell_PCH

ON


For internal use

Cell_PCH Impact on Spreading Code tree occupation (1)

Activation of this feature significantly reduces call setup time related to SRB. Setup_time parameter presented in User activity messages in Cell_DCH state section is much shorter, reduced from 2,8 to 0,7 second.

With Cell_PCH feature time when SRB is established is ~24% shorter (with default parameter set) comparing to situation without this feature activated in the network.

Shorter period of time when SRB is sustained has direct impact on Spreading Code tree occupation.

Next slides present exemplary situation when feature is disabled and enabled for the following parameters.


For internal use

Cell_PCH Impact on BaseBand occupation

Activation of this feature significantly reduces call setup time related to SRB. Setup_time parameter presented in User activity messages in Cell_DCH state section is much shorter, reduced from 2,8 to 0,7 second. This means that SRB Baseband resources will be occupied by shorter time period.

With Cell_PCH feature time when SRB is established is ~24% shorter (with default parameter set) comparing to situation without this feature activated in the network.

Next slides present exemplary situation when feature is disabled and enabled for the following parameters.

Smartphone related features RAN1913 High Speed Cell_FACH


For internal use

High Speed Cell_FACH Dimensioning impact

• Feature allows introducing higher Cell_FACH to Cell_DCH threshold – would not affect (increase/decrease) number of Keep Alive messages sent in FACH

• Feature would affect number of user activity messages sent in Cell_FACH if their size is below threshold

• Feature would affect code tree occupation if user activity messages are sent in Cell_FACH (size of user actvity message below threshold)

• T2 timer settings can affect number of RRC states changes


For internal use

User activity messages via HS_FACH

Parameters definition:

• Threshold for going to DCH – 128 bytes was introduced as UL TVM threshold for Release 99 RACH.

– It is also recommended to apply 128 bytes for Release 7 UEs

– for Release 8 UEs, it is recommended to support HTTP request of typically 500 bytes

– the TVM threshold should be higher, e.g. at least 512 bytes.

• T2 timer meaning and value for HS FACH (additional) (CTS from CELL_FACH to CELL_PCH)

– Existing inactivity timer for Release 99 UE could be applied for Release 7 UEs in order to move from CELL_FACH to CELL_PCH.

– for 3GPP Release 8 UEs, it is recommended to keep such UEs longer in CELL_FACH, hence a separate inactivity timer for Release 8 UE is proposed.


For internal use

High Speed Cell_FACH Impact on air interface load (1)

This feature will act (transmission will be performed in Cell_FACH state over HS-PDSCH channel) only if the following two conditions will be fulfilled:

• Size of user / Keep Alive message is higher than Downlink / Uplink traffic volume measurement low threshold

• Size of user / Keep Alive message is lower than Downlink traffic volume measurement threshold of HS-FACH

For default parameter set size of user / Keep Alive message has to be higher than 128 but lower than 2048 Bytes.

From cell load perspective the following parameters will change due to transmission over E-DCH in UL and HS-PDSCH in DL:

• UL spectral efficiency (UL_spectral_eff)

• DL spectral efficiency (DL_spectral_eff)


For internal use

High Speed Cell_FACH Impact on air interface load (2)

To show how this feature affects air interface load an example was prepared base on parameters presented below.


For internal use

High Speed Cell_FACH Impact on Spreading Code tree occupation

• T1 – for HSDPA and HSUPA value of this timer is set to 0. It has significant impact on Spreading Code tree occupation time because transmission resources are released after transmission of each message (no Spreading Code reservation during inactivity).

• In_control_plane_TSC

• Out_control_plane_TSC

For HSDPA and HSUPA there is no Spreading Code occupation caused by control plane because signaling information are sent together with data. Value of this parameters will equal 0.

• Soft_HF

• Softer_HF

During HSDPA transmission there are no links in Soft or Softer Handover. Parameters will be equal 1.


For internal use

High Speed Cell_FACH Impact on Spreading Code tree occupation

• DL_SF – value of DL Spreading factor will change to 16.

To show how this feature affects Spreading Code tree occupation an example was prepared base on the same parameters as for air interface load.


For internal use

High Speed Cell_FACH Impact on Baseband occupation

HS Cell_FACH

OFF

HS Cell_FACH

ON

Lower

BaseBand

occupation

due to

shorter

occupation

time of HS-

PDSCH

channel

Below example of Baseband allocation is shown with the same input

assumption as for Spreading Code tree occupation example

Smartphone related features RAN2136 Fast Dormancy


For internal use

Fast Dormancy Impact on Smartphone Dimensioning Method

Features impact:

• Time in Cell_DCH state

– After expiration T323 timer (default 0 sec.) UE informs that has no more data to send – Signalling Connection Release Indication message is sent to RNC with Signalling Connection Release Indication Cause set to UE request PS Data Session end

– UTRAN should move UE to low battery consumption mode (Cell_PCH) as soon as possible

• RRC Signaling

– UE is kept in Cell_PCH instead of idle_mode – lower number of RRC messages which have to be send

Feature gives possibility for the UE to inform network when would like to go to low battery consumption mode – shorter time in Cell_DCH and less signalling due to

stay in Cell_PCH


For internal use

Fast Dormancy Impact on Spreading Code tree occupation (1)

Activation of this feature reduces inactivity timer T1 from default 5 to 0 seconds for transmission performed on Rel99 DCH channel.

It has significant impact on Spreading Code tree occupation time because transmission resources are released after transmission of each message (no Spreading Code reservation during inactivity).


For internal use


Fast D

orm

ancy

Off

Network Traffic

Number of Subscribers 2000

Smartphone application penetration 13% Network Features

Fast Dormancy No

CCCH Setup No

Cell_PCH No

HS Cell_FACH No

FDPCH No

SC Results

SC

Incoming User Messages related attempts per user in BH 20.0

User Plane Spreading Code Occupation Time Related to Single User Message [ms] 6000.0

Control Plane Spreading Code Occupation Time Related to Single User Message[ms] 8800.0

Used Service DCH

Outgoing User Messages related attempts per user in BH 20.0



Used Service DCH

Keep Alive related attempts per user in BH 40.0



Used Service DCH

DCH - User Plane Total Spreading Code Occupation Time [h] 44.9

DCH - Control Plane Total Spreading Code Occupation Time [h] 67.6

HS-DSCH - Total Spreading Code Occupation Time [h] 0.0

Spreading Code Tree Occupation [%] 61.51%


For internal use

SC Results

SC

Incoming User Messages related attempts per user in BH 20.0



Used Service DCH

Outgoing User Messages related attempts per user in BH 20.0



Used Service DCH

Keep Alive related attempts per user in BH 40.0



Used Service DCH

DCH - User Plane Total Spreading Code Occupation Time [h] 4.4

DCH - Control Plane Total Spreading Code Occupation Time [h] 10.0

HS-DSCH - Total Spreading Code Occupation Time [h] 0.0

Spreading Code Tree Occupation [%] 7.33%


Reduction of spreading code tree ocupation due to

shorter inactivity time in Cell_DCH state

Network Traffic

Number of Subscribers 2000

Smartphone application penetration 13%

Fast D

orm

ancy

On

Network Features

Fast Dormancy Yes

CCCH Setup No

Cell_PCH Yes

HS Cell_FACH No

FDPCH No

Smartphone related features RAN2451 Fast Dormancy Profiling


For internal use

Fast Dormancy Profiling Impact on Smartphone dimensioning method

Feature impact:

•Shorter inactivity time in RRC states is used for UEs recognised as Legacy Fast Dormancy Phones

• Possibility to avoid unnecessary movement to IDLE_mode – lower signalling load

• Lower resources utilization due to faster leaving of Cell_DCH

• Longer battery life due to shorter time in Cell_DCH and Cell_FACH stated

• Higher traffic volume thresholds

• Possibility to avoid unnecessary movement to Cell_DCH – only for sending Keep Alive message

• UE recognised as LFD Phone is remembered by RNC - RNC checks if Iu-PS connection for this UE already exist. If Iu-PS connection already exists then is used for transmission.

Feature enables possibility to identify legacy Fast Dormancy phones

which cause unnecessary signaling load. Those phones are moved to

Cell_PCH instead of IDLE_mode due to shorter inactivity timers

Smartphone related features RAN2167 State Transitions Counters


For internal use

State Transitions Counters Impact on Smartphone dimensioning method

Feature impact:

• Better view on the RRC states transitions at the cell level

• Possibility to better monitoring following activities:

– Fast dormancy phenomena

– Low connection establishment success rates

– Ratio of successful transitions between RRC states

– RRC states changes from E-DCH/HS-DSCH to Cell_FACH

– Verification of timers optimization

– Verification of threshold optimization

New counters at the cell level are introduced that can be used to

calculate the statistic related with RRC states changes. Especially

with Smartphone's activity

Verification of threshold optimization

Impact of changes in data threshold

which define how much data could be

sent via HS-Cell_FACH

Th

resh

old

Valu

e

# o

f R

RC

Sta

tes

Tra

ns

itio

ns

State transition from Cell_PCH to Cell_DCH

State transition from Cell_PCH to Cell_FACH

The End

3G Smartphones Impact

Documents

Transcript of 3G Smartphones Impact