HSUPA device design: Find issues earlier, resolve issues ... · PDF file• Troubleshooting...

HSUPA device design:Find issues earlier, resolve issues faster

1

Agenda

• Introduction

• Example mobile device development lifecycle

• Potential HSPA design issues

• Troubleshooting methodology

• Agilent 8960 Lab Application tools

• Examples HSPA issues resolved

• Summary

• Q & A

• Closing

2

Introduction – Forces affecting mobile design

• Devices no longer just voice –many integrated features and services

• Standards evolve in parallel with hardware and software design

• Competition among device suppliers is strong!

3

Introduction – Forces affecting mobile design

• Technologies and implementation across models varies dramatically

• The typical mobile phone does not exist

A-GPS

WCDMA

GSM

1xEV-DO

CDMA2000 EGPRS

S-DMB

FM Radio

802.11

Bluetooth

DVB-HHPiDAB

2-way Radio

WiBroWiMax

iR

HSPA/HSPA+

4

Introduction – Mobile Design Trade-offs

• Some optional features for networks are mandatory for devices

– For example, phones must support global networks and system infrastructures

• More internet applications & emerging services

– Require phones support many multimedia sources, but also be small, cheap, and consume a minimum of energy.

Objective Trade-offs

Design Objective Processors On-chip memory Off-chip memory

High processing performance AdvancedFast Many Some

Fast

Cost-effectiveness Notadvanced Few Few

Slow

Small energy consumption Energy-efficient Many (few off-chip accesses) Energy-efficient

Flexible platform – supports all SW and quickly customizable Optimize trade-offs of the above

5

Agenda

• Introduction






• Summary

• Q & A

• Closing

6

Example Mobile Device Development Lifecycle

•Mechanicals

•PCB Layout

•Custom Features

•Localization

•Integration/Verification (product)

PRODUCT

Product Development

•Architecture (building blks) – DSP, uC, OS, RF choices

•Design – RF, L1, L1/2, L3/4, Applications

•Testing of each design element

•Integration/Verification (platform)

Platform Development (high, med, low end, and smart phone)

Technology Development &

Labs

Component Development

PRODUCT •Pre-IOT

•Stress test

•System test

•Modem functional /performance

•Conformance (signaling, RF, apps)

REF DESIGN

Validation

Test House Certification

(e.g. GCF, Type Approval)

Operator Acceptance

Field Tests

PRODUCT

PRODUCT

PRODUCT

REF DESIGN

REF DESIGN

REF DESIGN

REF DESIGN

Multiple Loops

External Testing

NEM Infra Lab

PRODUCT

REF DESIGN

7

Multiple Loops

Multiple Loops

Importance of finding / resolving issues early

• Less costly to fix

• Less complex to fix

• Less chance of collateral damage(fix one thing, break two others…)

• Less chance of customer or user exposure

• Less impact to company/product reputation

• But most importantly…

8

$

OFF

$

OFF

Importance of finding / resolving issues early

• Less costly to fix

• Less complex to fix

• Less chance of collateral damage(fix one thing, break two others…)

• Less chance of customer or user exposure

• Less impact to company/product reputation

• But most importantly…

Improves TTM and potential profit $$

9

$

OFF

…

Example Mobile Device Development Lifecycle

•Mechanicals

•PCB Layout

•Custom Features

•Localization

•Integration/Verification (product)

PRODUCT

Product Development

•Architecture (building blks) – DSP, uC, OS, RF choices

•Design – RF, L1, L1/2, L3/4, Applications

•Testing of each design element

•Integration/Verification (platform)

Platform Development (high, med, low end, and smart phone)

Technology Development &

Labs

Component Development

PRODUCT•Pre-IOT

•Stress test

•System test

•Modem functional /performance

•Conformance (signaling, RF, apps)

REF DESIGN

Validation

Test House Certification

(e.g. GCF, Type Approval) Operator

Acceptance

Field Tests

PRODUCT

PRODUCT

PRODUCT

REF DESIGN

REF DESIGN

REF DESIGN

REF DESIGN

Multiple Loops

External Testing

NEM Infra Lab

PRODUCT

REF DESIGN

6

Multiple Loops

Multiple Loops

Integration and Validation Example TasksPhysical layer integration- Send power control bits, ensure mobile scales for HSDPA

power and ramps DPCH power as required- Place the phone into compressed mode to make inter-

frequency measurements, evaluate returned values

Protocol functional test- Order interfreq meas in unsupported band, see response- Reject PDP context, check response and reported cause

Application/OS integration- Stream video, impair downlink (change data rate, add

fading), see if dynamic buffering compensates- Run applications and evaluate CPU loading

Real-world test, user experience- FTP a file, impair downlink (induce fading, add AWGN and

change data rate), monitor data throughput- Order an inter-RAT cell reselection while streaming video,

receive an SMS, evaluate message reception and video quality

Stress test- Run tests 1000s of times looking for memory leaks or

buffer overruns, transfer data at phone’s max specified rate

- Run applications simultaneously to look for application interference/interaction, find corner case problems

- Analyze current drain and battery life during data transfer, handovers, cell access, etc.

Ensure the mobile works as designed

Stress it, find issues

10

Agenda

• Introduction






• Summary

• Q & A

• Closing

11

Potential design issues – Physical layer integration

• UEs may have power control issues due to power variations introduced by HSUPA

• Due to very dynamic uplink, UEs may improperly construct code channels

• These changes cause more out-of-channel interference and poorer modulation quality

12

Potential design issues – Protocol functional test

• UE responds to network commands incorrectly or too slowly (HSDPA fast scheduling requires faster response)

• Messaging between Node B and UE happens in wrong order, at wrong time, or with wrong message

• UE does not ignoreinfo it should ignorei.e. whatever it doesn’t support

• Handovers do not happen seamlessly – data connectionsuspended improperlyand/or voice call dropped

13

Potential design issues – Application/OS integration

• Memory management, keeping buffers level loaded

• Problems with loss in a connection

• Intolerant to changes in throughput speed

• Long delays can cause problems

• Managing interrupts and concurrent activities – e.g. an SMS arriving during a video call

• Mobile internet different than wired due to handovers and re-connections

1. Variations in delay2. Variations in bandwidth

14

Data applications

Mapping

Gaming

Camera/video

Enterprise

Secure transactions

Messaging

Applications

Potential design issues – Real-world /Stress test

• Real-World: UE doesn’t perform as designed when used in a real user environment

• Stress Test: Extreme combinations of HW/protocol/OS/apps interactions causes undesired results. Some examples:

• Battery drain – Every aspect of device design affects battery life! Battery drain is of primary concern due to its direct impact on the user’s experience and can also be an indicator of hidden design issues.

• Issues found here span entire cross-section of phone’s design: HW, all layers of protocol, OS, applications.

15

Agenda

• Introduction






• Summary

• Q & A

• Closing

16

A methodology for finding and resolving issues

Step 3 – Validate UDP application• PS data call• “Darwin Server” (for example)

– Time-sensitive data• Data throughput monitor

Step 4 – Validate TCP and System• PS data call• “ftp”

– Payload critical data• Data throughput monitor

Step 1 – Validate RF and MAC• RB Test Mode call• “User Defined Channel”• HBLER measurement

– Real-time results• WTM for RF parametric performance

Step 2 – Validate RLC, Driver, and IP• PS data call• “UDP Flood”

– Defined data rate– No acknowledgements

• Data throughput monitor

17

Step 5 – Real World / User Exp Test Step 6 – Stress Test• “User Defined” PS data call• Active CQI, Fading, Serving grants, Services,

Handovers, Data throughput monitor, more…• Interactive Functional Test software

• Same as Step 5 with combinations aimed at extreme scenarios that break device

A methodology for finding and resolving issuesStep 1 – Validate RF and MAC• RB Test Mode call• “User Defined Channel”• HBLER measurement

– Real-time results• WTM for RF parametric performance

A methodology for finding and resolving issuesStep 2 – Validate RLC, Driver, and IP• PS data call• “UDP Flood”

– Defined data rate– No acknowledgements

• Data throughput monitor


20

Step 3 – Validate UDP application• PS data call• “Darwin Server” (for example)

– Time-sensitive data• Data throughput monitor


Step 4 – Validate TCP and System• PS data call• “ftp”

– Payload critical data• Data throughput monitor


22

Step 5 – Real World / User Exp Test Step 6 – Stress Test• “User Defined” PS data call• Active CQI, Fading, Serving grants, Services,

Handovers, Data throughput monitor, more…• Interactive Functional Test software

• Same as Step 5 except goal is find out where device ‘breaks’ and why

Function Tests• Current Drain• SMS (MO, MT)• MMS(MO,MT)• ftp, http, UDP• Call Processing• Network

impairments

Parallel Activities •more realistic user experience

Device Automation

Tools

Current Drain Monitoring

Agenda

• Introduction






• Summary

• Q & A

• Closing

23

Tools – Wireless Protocol Advisor

• Real-time logging / post capture analysis

• Collect and interpret protocol messages, verify functionality, isolate/resolve protocol issues quickly

24

Tools – Data Throughput Monitor

• Graphically view OTA and IP throughput of data transmitted and received by the UE

– Current, Average, Peak, and cumulative data is reported for most recent 600 seconds

• Test data throughput while simulating RF impairments to validate device and application performance

• Demonstrate device and application performance under high-speed data rate operation

25

Tools – 2-Cell Handovers

• One common place for errors to occur is during handovers

• Test application’s performanceduring handovers to ensure:• Data flow and/or voice call continues

once handover is complete• Data call is dropped if transitioning

from dual transfer mode (DTM) cellto voice only cell

26

Tools – Automation Software

Wireless Test Manager (WTM)

• Performs TA and LA automation of RF parametric testing for wireless device design

– Does HW and L1 pass the standards?

• Provides LA Automation of Functional Test processes not defined in industry standards

– Does the HW, L1/L2/L3, Services, and Applications behave as expected to on a real network connection?

Interactive Functional Test (IFT)

Group/Presentation TitleAgilent Restricted

Month ##, 200X

Agenda

• Introduction






• Summary

• Q & A

• Closing

28

Example issues resolved – Physical layer integration

Problem: During packet data testing, frequent data “drop outs” were observed

Tools: PS data call, UDP flood, Data Throughput Monitor, DL channel configuration modifications (1) turn off E-RGCH power; (2) turn off E-RGCH signaling

Outcome: UE was detecting E-RGCH Tx as “DOWN” instead of “HOLD” – when E-RGCH signaled as “OFF” problem was resolved.

29

BEFORE AFTER


• Problem: During physical layer throughput testing, for given AG we expected a certain E-TFCI, transport block size, and throughput but found some differences.

• Tools: RB test mode call, Serving Grant modifications, E-TFCI Recorder, HSUPA Info report

30

Quantized betas

Unquantizedbetas

AG

xput(kbps)

AG

xput(kbps)

0 1.8 0 1.81 1.8 1 1.82 1.8 2 1.83 1.8 3 1.84 35.9 4 35.95 71.6 5 71.66 137.1 6 103.27 137.1 7 137.18 137.1 8 137.19 137.1 9 137.1

10 137.1 10 137.111 137.1 11 137.112 174.9 12 174.913 174.9 13 174.914 174.9 14 174.915 174.9 15 174.916 174.9 16 174.917 205.8 17 205.818 205.8 18 205.819 205.8 19 205.820 273.5 20 242.121 348.9 21 308.922 482.8 22 378.423 482.8 23 482.824 754.7 24 616.125 962.9 25 754.726 2000 26 962.927 2000 27 1228.628 2000 28 1505.129 2000 29 1920.430 2000 30 200031 2000 31 2000

Unquantized β Quantized β


• Outcome: It was discovered that UE uses unquantized beta values (throughput vs. AG is smoother). E-TFCI recording helped understand differences in UE implementations

31

Match Table 0TS 25.321, App B.3 values

Expected 137 kbps

Example issues resolved – Protocol Functional Test

• Problem: UE did not properly respond to network initiated cell re-selection

• Tools: 2-cell handover, WPA

• Outcome: This capability was thought to have been tested previously but it was found that the device actually had a protocol issue that prevented the cell re-selection order from completing correctly.

8960 simulating cell #1

Turn cell #1 power down

Cell #2 status should change from idle registering idle again

Device should detach from cell #1 and attach to cell #2

32

Cell #1 Cell #2

Example issues resolved – Application Integration

• Problem: Observed UE call disconnections during streaming video application

• Tools: PS data call, WTM, Serving grant pattern, E-TFCI recording

• Outcome: Found UE data buffering issue when subject to repetitively alternating AG between 0 and 31 (minimum to maximum) over period of several minutes. . Tricky to keep buffers from overflowing but not have them too empty or too full.

33

Call drops

Example issues resolved – Application Integration

• Problem: When running FTP downloads some HSPA UEs had difficulty achieving and sustaining maximum IP data.

• Tools used: Data Throughput Monitor, WPA logs

• Outcome: It was found that UE’s IP data throughput may be degraded by RLC polling rate that stresses UE processing capacity. Reducing the RLC polling rate allowed these UEs to more stably maintain higher data rates.

34

20 ms between responses Vs.

120 ms between responses

Example issues resolved – Real-world/Stress test

• Problem: Video streaming application did not respond to channel quality changes as fast as desired.

• Tools: Data Throughput Monitor, WPA, streaming video server, CQI changes

• Outcome: Server buffering algorithm was redesigned.

35

Example issues resolved – Real-world/Stress test

• Problem: A data security application intermittently used 100% of a phone’s CPU capacity until an email message was sent to the phone.

• Tools: Current drain analysis software, PS data call, channel quality changes, battery drain software

• Outcome: Unforeseen application interactions impacted an unrelated service – it was difficult to replicate this scenario manually but fairly simple with above tools

36

Agenda

• Introduction






• Summary

• Q & A

• Closing

37

Summary

• Mobile phones are complex systems despite a small physical size. With functions that span business, pleasure, and commerce. This fuels the design challenges associated with conflicting demands on performance, cost, size, and flexibility.

• Thorough testing of an HSPA devices is similarly complex!

– physical layer testing only provides an initial indication of performance, but is not sufficient to obtain an accurate picture of how a UE will perform under real-world scenarios.

– application layer performance has the greatest impact on the end user experience.– Each layer of the protocol stack has multiple interactions, any or all of which can have an impact on the

final application layer throughput delivered to the end-user. – Physical layer variables such as power control, code power levels, and channel configurations can all

significantly impact the performance of a UE or application.

• A thorough test process for HSPA devices starts with the standards (i.e. 3GPP), but then needs to be extended beyond these conformance-based requirements to reflect the dynamic HSPA network environment which is built and implemented based on trade-offs. This ensures efficient network resource allocation and maximizes end user experience.

38

Q & A

39

Closing Comments

• Thank you for attending!

• Additional recommended live events to improve your mobile device designs and time to market:

1. Optimize Your Mobile Device Run-time using Innovative Battery Drain Analysis Techniques – Wednesday, Jan. 23, 2008 10-11am PST, 1-2pm EST

Learn how to conduct crucial battery drain characterization tests under real-world RF call conditions using program automation. This webinar provides an overview of innovative techniques for characterizing and analyzing battery drain for validating and optimizing wireless mobile device operating times.

Registration link: www.agilent.com/find/BatteryDrainWebcast2. New bench-top test technique to ensure that mobile phone designs work on real

networks – Thursday, Mar. 6, 2008 10:00-11:00am PST, 1:00-2:00pm ESTLearn about a new technique to find design issues early in the design process and on the bench-top. The technique involves stressing mobile devices in executing multiple and simultaneous, real-time, real-world user applications and network operations to identify design problems that would only show up when mobiles are used in mass on live networks.

Coming soon at: http://techonline.com/learning/livewebinar/

40

http://www.agilent.com/find/BatteryDrainWebcast

http://techonline.com/learning/livewebinar/

HSUPA device design: Find issues earlier, resolve issues ... · PDF file• Troubleshooting...

Documents

Transcript of HSUPA device design: Find issues earlier, resolve issues ... · PDF file• Troubleshooting...