VDF-D2 MMS delivery too

long

H.Fischer
040715 (2) VDF MMS delivery too long INTERNAL V3.1.ppt

MMS delivery too long: Case1: RNC Iu release after

authentication Request from UMSC
Short description/impact on network:
20.1.04 case1: VDF-D2:The delivery-time of a MMS using Samsung
Z100 mobile camped on 3G takes 35 second longer as normal. This is
measured from pressed SEND-button at A-subscribers until indication at
B-subscribers that MMS has been received with auto-download active at
B-subscriber. VDF RFP from 31.7.03 requires MMS elapsed time
(30kbyte)<5s, 95%. Interpretation is unclear
30.6.04 case2: VDF-SFR: Sporadically, the delivery time of a 100k MMS
is too long, because of throughput problems with the 64k/64k bearer. The
contractual requirements are fulfilled however sometimes download time
is 84s instead of required 60s
Progress/applied actions (1):
Case1: FEKAT I85232 in UMR2.0
The first received traces do not report the necessary information for
analysis, because RNC internal trace is started after the authentication
message. (which fails).
Page 2

Siemens, 2002

RNC Iu release after authentication Request from

UMSC
Progress/applied actions (1):
Analysis shows, that the issue occurs always when SREQ (piggybacked
on SCCP CR establishing Iu PS connection to SGSN), for the download
of the MMS, is sent between Iu Release Command from UMSC
terminating the SMS and the consequent RRC Connection Release sent
from RNC to the UE. This is always the case when the Samsung Z100
UE is set to auto-download after the SMS.
Consequence is a protocol overlapping, because the SREQ
message is sent by UE on resources, which are about to be released
by RNC.
The UE waits 32 sec. after the first failed Auto-Download before retransmission (new Service Request message), summing up in the
download time of 40s. The timer is not configurable by the Network,
because it is hard-coded in the mobile.

Page 3

Siemens, 2002

RNC Iu release after authentication Request from

UMSC
Progress/applied actions (3):
Test of software adaptation (Patch solution) to modify the time of
sending IU Release Command by Core Network towards the RNC
Workaround for problem introduced only for Samsung Z100 Mobile
Time Values for sending IU Release Command 700 / 1200 ms
Test with Samsung Z100 in Test-lab shows a correct behaviour and download time
is around ~ 35 sec
Tests with other mobile types (Motorola A835) show also a correct behaviour.
Tests in UMR3.0 without any workaround and software adaptation:
Test with Motorola A835 Terminal in Test-lab shows a correct behaviour and
download time is around ~ 32 sec.
Test with Nokia 6650 terminal done in VFD2 field shows correct behaviour and
download time is around ~ 33 sec.
Tests with new Samsung Z105 show also correct behaviour and a download time
around of ~35 sec.

On customer request: planned tests with Samsung Z100 in GPRS

environment to verify if problem arise in 2,5G network as well (due
date 11.03.2004).
Page 4

Siemens, 2002

Protocol Racing with terminal Samsung Z100-K6 in

UMR2.0/UMR3.0 (exact flow shown for UMR3.0)
SGSN
3G MSC

RNC

NodeB

Terminal

last CPAC (notification SMS to Terminal, CS domain on IU)

~ 200 ms
~ 50 ms

IU Release CMD (CS)

RRC Conn Release , (CS/PS domain not existing on IuB)

~ 134 ms
~ 80 ms

~ 374 ms

Service Request (to download MMS on existing resources)

RRC Release Complete (no resources exist anymore)

SREQ ( PDP Context)

Authentication Req
IU Rel (PS)

Service Request (on new resources does not happen)

X on IuB)
X (no resources exist

T3380=30 s
(3GPP 24.008)

IU Rel Complete (CS)

Service Request repetition (on new resources after NAS timer)

Page 5

Siemens, 2002

Protocol Racing: comments to the flow chart

Notification SMS is send to UE starting an application to download MMS

after 324 ms

Resources on IuB, Uu are released. Resource Releasing can not be

stopped. The previous service request must fail

Sending request on still existing resources (IuB,Uu) is correct. No distinction

between PS/CS exists on IuB/Uu.
Release of resources already arrived at UE, UE should signal unexpected release
due to its own application.

RNC releases CS/PS, because no PS call active at that time: Correct behaviour
UE repeat SREQ during period of timer T3380 = 30s in mobile, because mobile
detects release of resources according to 3GPP. Timer is fixed in UE an can not be
changed. That is the reason for delayed download time of 72s vs. 45s

Iu CS release could be delayed by 3GMSC in order to solve the problem

with Samsung Z100

If message IU Release CMD is sent significantly later (>/=700 ms) the racing
condition will not exist anymore, as long as the reaction time of the application
remains unchanged
Core patches to delay IuRelCMD can be developed, delay Time(700ms/1200 ms).
Therefore additional tests with all common mobiles must be done.

Page 6

Siemens, 2002

RNC Iu release after authentication Request from UMSC after

patch introduction (~700 ms delay) with Samsung Z100.
UE
Samsung
Z100

RNC

MSC
Last CPAC (SMS)

Last CPAC (SMS)

SREQ

SGSN
250 ms

Iu Release Command (no patch)

516 ms
SREQ
23 ms

ACRQ/IDRQ
Iu Release Request (no patch)
710 ms

170 ms
Iu Release Command (700 ms patch)

Page 7

Siemens, 2002

RNC Iu release after authentication Request from UMSC after

patch introduction (~700 ms delay) with Motorola A835.
UE
Motorola
A835

RNC

MSC
Last CPAC (SMS)

SGSN

Last CPAC (SMS)

SREQ

635 ms
SREQ
29 ms

ACRQ/IDRQ

705 ms
40 ms
Iu Release Command (700 ms patch)

Page 8

Siemens, 2002

No Protocol Racing in UMR 3.0

(with terminal Motorola A835, without core patch)
SGSN
3G MSC

RNC

NodeB

Terminal

last CPAC (notification SMS to Terminal, CS domain on IU)

~ 200 ms
~ 50 ms

~ 239 ms

IU Release CMD (CS)

RRC Conn Release , (CS/PS domain not existing on IuB)
RRC Release Complete (no resources exist anymore)

~ 454 ms
~ 120 ms

RRC Conn Request (on new resources)

MMS procedure continues

according to expected flow,
MMS download to terminal B
is completed in ~32 sec.
Page 9

Siemens, 2002

No Protocol Racing in UMR 3.0

(with terminal Samsung Z105, without core patch)
SGSN
3G MSC

RNC

NodeB

Terminal

last CPAC (notification SMS to Terminal, CS domain on IU)

~ 250 ms

IU Release CMD (CS)

RRC Conn Release , not traced

RRC Release Complete , not traced

6144 ms

RRC Conn Request , not traced

RRC Connection Setup

6593 ms

SREQ

MMS procedure continues

according to expected flow,
MMS download to terminal B
is completed in ~35 sec.
Page 10

Siemens, 2002

No Protocol Racing in UMR 3.0

(with terminal Nokia 6650, without core patch)
SGSN
3G MSC

RNC

NodeB

Terminal

CPAC
ATRQ
CPDA

-91 ms

Last CPAC
ACRQ
ACRE
ATAC
ACOM

MMS procedure continues

according to expected flow,
MMS download to terminal B
is completed in ~33 sec.
Page 11

Siemens, 2002

Case1: Conclusion
Conclusions:
Protocol racing exists only with mobile Samsung Z100 in auto-download mode.
Motorola A835 ,Samsung Z105 and Nokia 6650 are working correctly
Solution with pre-developed Patches for the 3GMSC in UMR2.0/UMR3.0 and
UCR2.1 in our testbed have shown that the protocol overlapping effect with
Samsung Z100 does not arise anymore. No side-effects on Motorola A835 and
Nokia 6650 terminals.
Test with Motorola A835 Terminal shows a correct behaviour and the download
time is around ~ 32 sec.
Tests with Nokia 6650 Terminal shows a correct behaviour and the download
time is around ~ 33 sec.
Test with the new Samsung Z105 shows a correct behaviour and the download
time is around ~ 35 sec.
MMS Problem is neither a failure in the network nor a failure of the mobile
Samsung Z100. It is simply a timing problem (protocol overlapping)
between a mobile and Siemens network. This problem does not occur any
more with the new Samsung mobile Z105, because the auto download to
get the MMS will be started about 6 seconds later. This behaviour has to
be verified with all other new mobile types.

Page 12

Siemens, 2002

Case2: MMS delivery too long (64/64k bearer)

Progress/applied actions (2):
2.7.04:
Theoretical lower boundary for up/download time of 100k MMS is app. 45s. In uplink,
upload time is however randomly app. 20s longer
Additional 7s delay are occasionally observed in DL (server?)
User plane shows no re-transmissions, RX win-size is not reached (ok), but throughput
on IuB seems to oscillate every 1,2s (520ms ok, 650ms very low).. Apparently higher
layers are not transmitting on a constant data-rate. Actis 82859 opened

1,2s

Page 13

Siemens, 2002

Case2: MMS principal message flow of and minimum

up/download time of a 100k MMS on 64/64k RAB
SGSN

3G MSC

RNC

UE1

UE2

RRC Conn setup

5,5s

PDP context accept

12,5s

Upload 100k MMS (UL)

paging
push SMS to

~8s

download MMS
RRC Conn setup

5,5s

PDP context accept

12,5s

download MMS (DL)

min. MMS time ~45s

Page 14

delay UE
application

Siemens, 2002

Case2: MMS delivery too long (64/64k bearer)

Solution plan
UE user profile for MMS to use 384k bearer would save in DL ~10s
Suspect that operating Z105 in trace mode and or data transmission of
UE causes oscillation. UE traces are not available to Siemens
Samsung
Clarify throughput oscillations on higher layers (RLC ok) Samsung

Page 15

Siemens, 2002