Iub Events Definition in UMTS-Unify3G v1_0

7/28/2019 Iub Events Definition in UMTS-Unify3G v1_0

1/32

Iub Event Definition in UMTS Unify3G v1.0 November 2005

AnnexIub Event Definition in UMTS Unify3G v1.0

November 2005


2/32


Confidential and Proprietary

Copyright

1998-2005 Actix Ltd. All Rights Reserved.

No part of this publication may be copied, photocopied, reproduced, transmitted, transcribed, orreduced to any electronic medium or machine-readable form without the prior written consent ofActix Ltd.

All brand names and product names included in this book are trademarks, registeredtrademarks, or trade names of their respective holders.


3/32


Actix Confidential and Proprietary Page 3

Contents

1

INTRODUCTION............................................................................................................4

1.1 DIAGRAMS OVERVIEW .............................................................................................4

2 CS EVENTS...................................................................................................................5

2.1 UMTS_IUB_CSCALL_OUTGOING DIAGRAM............................................................5

2.2 UMTS_IUB_CSCALL_INCOMING DIAGRAM.............................................................8

2.3 CS_RADIO_BEARER_HANDLING DIAGRAM .............................................................9

2.4 IUB LOCATION UPDATE DIAGRAM ..........................................................................10

2.5 ATTRIBUTES FOR CS ON THE IUB INTERFACE ........................................................11

3 PS EVENTS.................................................................................................................19

3.1

IUB PSCALL DIAGRAM..........................................................................................19

3.2 PS_RADIO_BEARER_HANDLING DIAGRAM............................................................22

3.3 IUB_UMTS_SMDIAGRAM.....................................................................................23

3.4 IUB_UMTS_GMM DIAGRAM .................................................................................25

3.5 ATTRIBUTES FOR IUB PSCALL HANDLING.............................................................27

4 OVERVIEW OF IUB CALL TRACKING FEATURE...................................................32


4/32



1 Introduction

The Event Diagrams based on Iub Interface signaling have been redesigned.The following analyses were modified:

- CS Call Handling and Mobility Management

- PS Call Handling, GPRS Mobility Management and Session Management

The scope of this document is to describe the new diagrams and associated attributes.

The last chapter is an overview of the Iub Call tracking mechanism.

1.1 Diagrams ov erview

Previously the event diagrams were arranged in the following way:

XML Filename Diagram name Type of Analysis/Event

Call_State_01UMTS_Iub_Events.aev

Location_Update

UMTS_Iub_Data_Events.aev UMTS_Data_Diagram

This is the new structure:

XML Filename Diagram name Type of Analysis/Event

UMTS_Iub_CSCall_OutgoingMobile Originated (MO) CScall handling

UMTS_Iub_CSCall_IncomingMobile Terminated (MT) CScall handling

Iub_CSCall_Handling.aev

CS_Radio_Bearer_HandlingCS Radio Bearers (Setup,Release)

Iub_LocationUpdate.aev Iub_Location_UpdateCS Mobility Management(LAU, IMSI Attach, Detach)

Iub_PS_CallMobile Originated (MO) andMobile Terminated (MT) PScall handling

Iub_PS_Event_Layer.aev

PS_Radio_Bearer_HandlingPS Radio Bearers (Setup,Release, Reconfiguration,Bitrates)

Iub_UMTS_GMM.aev Iub_UMTS_GMMPS Mobility Management(RAU, PS Attach, PS Detach)

Iub_UMTS_SM.aev Iub_UMTS_SM PDP Context Handling

Iub_SHO.aev Iub_SHO Soft/Softer Handover analysis


5/32



2 CS Events

Events in the CS domain are referred to services like AMR Voice Call, UDI Video Call, SMS andMobility Management procedures (IMSI Attach, Location Area Update, IMSI Detach).

Current Iub diagrams analyze these main procedures/services:

MOC (Voice and video)

MTC (Voice and video)

Location Area Updates

IMSI Attach/Detach

2.1 UMTS_Iub_CSCall_Ou tgo ing Diagr am

The scope of the Iub CS Call Outgoing diagram is to trace MO CS Calls, both AMR voice (12.2

kbps) and UDI Video (64 kbps), on the Iub interface. Originated SMSs are also tracked but noevents are set apart from the CS Call Type, which assumes the SMS value.

Here below is shown the criteria used for the main CS Call KPIs on Iub:

- Call Setup Failure (Iub_OutgoingCallSetupFail)

o The SCCP Connection is refused by the MSC

o CM Service Abort

o Anytime before CC:Alerting, release at NAS level with any of the following CC Causeclasses:

Resource Unavailable


6/32



Invalid Message

Protocol Error

NOTE: in case of release at NAS level without CC cause being indicated (theinformation is optional) the call setup is considered failed

o Normal Release at NAS level due to previous RAB Setup Failure

o Release of the underlying transport layer (RRC Connection) at anytime between RRCconnection Requestand CC:Alerting

- Early Terminated Call Setup (Iub_OutgoingEarlyTerminatedCall)

An Early Terminated Call is a call that does not reach the Successful Setup state but at the

same time is not considered a Call Setup Failure, for example because the called partyrejected the call. It is important to isolate these cases because they normally do notrepresent abnormal or failure scenarios in the network.

o Anytime between CC:Setup and CC:Alerting, release at NAS level with any of thefollowing CC Cause classes:

Normal Event

Service Option not Available

Service Option not Implemented

Typical examples of release cause that falls in these criteria are:

- User busy

- Call rejected

- Unassigned number

Also a NAS release with cause Normal Call Clearing during the Radio Bearer Setupprocedure is considered an Early Terminated Call Setup and not a Call setup Failure

- Call Setup Successful (Iub_OutgoingCallOk)

o CC:Alerting

o CC:Connect Ackin case CC:Alerting is not sent (e.g. called UE is switched off andanswering machine starts)

- Call Dropped (Iub_CallDropped)

A call drop event can be set only if the call reached the Successful Call setup state.

o If CC:Connect Ack message is not sent yet:

Release at NAS level with any of the following CC Cause classes:


7/32



Resource Unavailable

Invalid Message

Protocol Erroro If CC:Connect Ack message was sent:

Release at NAS level with any cause other than Normal Call clearing andNormal Unspecified

NOTE: in case of release at NAS level without CC cause being indicated (theinformation is optional) the call is considered dropped

o Release of the underlying transport layer (RRC Connection) not being preceded by arelease at NAS level.

-

Call Dropped beyond MSC (Iub_CallDroppedBeyondMSC)This is a special case of call drop event, which covers scenarios where the call is droppeddue to problems on the other leg of the call.

The signaling for these calls does not show any failure, but only a call release initiated bythe MSC at NAS level. The event therefore is useful to detect drop calls even in the casethe signalling do not reveal any failure scenario in the monitored leg of the call. The reasonfor not including this scenario in the normal Call DroppedKPI is the event reflects only theuser experience (the call drops for both users) but it does not represent an actualcommunication failure in the monitored leg of the call.

o After CC:Connect Ack message was sent:

Release at NAS level with cause Normal Unspecified

NOTE1: this event is peg only after reaching the Connect phase; if the MSC releases thecall with cause Normal Unspecified between the Alerting and Connect phases the call isconsidered Completed, to cope with the case of T301 expiry. Next release will allow theuser to specify the T301 value and event engine will be able to differentiate between a calldropped beyond MSC during Alerting and Connect phases and a call completion due toT301 expiry case.

NOTE2: as described in the previous KPI definitions, when MSC release the call with aNormal Event CC Cause Class before reaching the Alerting phase the event is stampedas Early Terminated Call Setup

- Call Completed (Iub_CallCompleted)

o If CC:Connect Ack message is not sent yet:

Release at NAS level with any of the following CC Cause classes:

Normal Event

Service option not Available

Service option not Implemented

o If CC:Connect Ack message was sent:

Release at NAS level with Normal Call clearing


8/32



- Call Handed Over to other Iub (Iub_CallHandedOverToOtherIub)

An Iub connection may be terminated because the UE has moved to an area that is notcovered in the logfile. In this case, the calls hand over to another part of the network andthis scenario is stamped by the event engine as a separated event, rather than a droppedcall.

The criteria used for detecting a call handed over to another Iub is:

o The last AAL2 connection for the call is released and all Radio Links have alreadybeen removed from the Active Set.

The exception is when the Radio Link are removed due to Cell_DCH to Cell_FACHtransition, however this does not apply to CS calls.

2.2 UMTS_Iub_CSCall_Inc om ing Diagram

The scope of the Iub CS Call Incoming diagram is to trace MT CS Calls, both AMR voice (12.2kbps) and UDI Video (64 kbps), on the Iub interface. Terminated SMSs are also tracked but noevents are set apart from the CS Call Type, which assumes the SMS value.

The criteria used for MT CS calls KPIs is the same as the one for MO CS calls (see previoussection).

These are the attributes associated to the main KPIs:


9/32



Call Setup Failure Iub_IncomingCallSetupFail

Early Terminated Call SetupIub_IncomingEarlyTerminatedCall

Call Setup Successful Iub_IncomingCallOKCall Dropped Iub_CallDropped

Call Completed Iub_CallCompleted

Call Handed Over to other Iub Iub_CallHandedOverToOtherIub

2.3 CS_Radio_Be arer_Handl ing Diagram

The scope of the Iub CS Radio Bearer Handling diagram is to trace the behavior of CS RadioBearers. Here below is shown the criteria used for the main CS RB KPIs:

RB Setup Failure (Iub_CSRadioBearerSetupFail)Precondition is the detection of a previous RRC: Radio Bearer Setup message in the CSdomain;

o RRC: Radio Bearer Setup Failure

o Release of the underlying transport layer (RRC Connection) anytime between RRC:Radio Bearer Setup and RRC: Radio Bearer Setup Complete

Successful RB Setup (Iub_CSRadioBearerSetupOK)


10/32



Precondition is the detection of a previous RRC: Radio Bearer Setup message in the CSdomain;

o RRC: Radio Bearer Setup Complete

RB Release Failure (Iub_CSRadioReleaseSetupFail)

Precondition is the detection of a previous RRC: Radio Bearer Release message in the CSdomain;

o RRC: Radio Bearer Release Failure

o Release of the underlying transport layer (RRC Connection) anytime between RRC:Radio Bearer Release and RRC: Radio Bearer Setup Complete

Successful RB release (Iub_CSRadioBearerReleaseOK)

Precondition is the detection of a previous RRC: Radio Bearer Release message in the CSdomain;

o RRC: Radio Bearer Release Complete

NOTE: In this version Channel Reconfiguration procedures in the CS domain (RB,transport channel, Physical Channel) are not handled.

2.4 Iub Locat ion Update Diagram

The scope of the Iub Location Update diagram is to trace Mobility Management activity of usersin the CS domain (MM) on the Iub interface.

Here below is shown the criteria used for the main CS Mobility Management KPIs on Iub:


11/32



- Location Update Failure / IMSI Attach Failure

The following scenarios trigger a LU Failure or a IMSI Attach failure depending on thevalue of Location Update Type field (Normal LU / Peiodic LU / IMSI Attach) precondition is the detection of a previous Location Update Request message:

o MM:Location Update Reject

o Release of the underlying transport layer (RRC Connection) at anytime betweenMM:Location Update Requestand:

MM:Location Update Acceptif this message does not include new TMSI

MM:TMSI Reallocation Complete if Location Update Accept messageincluded new TMSI

NOTE: the diagram does not check any of the LU related timers (T3210..T3213, T3240,

T3241 and T3250, T3255). Only at the release of the RRC connection in the two clausesabove listed will trigger the Location Update Failure event.

- Successful Location Update / Successful IMSI attach

The following scenarios trigger a successful LU or IMSI Attach depending on the value ofLocation Update Type field (Normal LU / Peiodic LU / IMSI Attach) precondition is thedetection of a previous Location Update Request message:

o MM:Location Update Acceptif this message does not include new TMSI

o MM:TMSI Reallocation Complete if Location Update Accept message included newTMSI

- Detach

o MM: Detach Indication

2.5 Att r ibutes for CS on the Iub interface

Attribute Values Triggers

Mobile Originated Calls Iub attributes

Iub_OutgoingCallOK 1 (Event)

Successful CS MO Call Setup

See description of KPIs in sec.

2.1

Iub_OutgoingCallSetupFail 1 (Event)

CS MO Call Setup failure

See description of KPIs in sec.2.1

Mobile Terminated Calls Iub attributes

Iub_IncomingCallOK 1 (Event)

Successful CS MT Call Setup


2.2


12/32




Iub_IncomingCallSetupFail 1 (Event)

CS MT Call Setup failure


CS Calls generic Iub attributes

Iub_CallCompleted 1 (Event)

Successful CS Call Completion.

Note there is no distinctionbetween MOC and MTC.


2.2

Iub_CallDropped

1 (Event) CS Call dropped. Note there is

no distinction between MOCand MTC.


Iub_CallDroppedBeyondMSC

1 (Event) CS Call was dropped for reason

beyond MSC, typically due toproblems in the other leg of the

call. Note there is no distinctionbetween MOC and MTC.


Iub_CallHandedOverToOtherIub

1 (Event) The call handed over to an Iub

interface that is not traced in the

logfile



13/32




Iub_CallSetupFailCause

Setting up RRC

ConnectionRRC Connection set

up

Security Mode ongoing

Security Mode OK

Security mode Failed

RB Setup ongoing

RB Setup OK

RB Setup Failed

RB Release ongoing

RB Release OKRB Release failed

RRC Released

RRC Setup Failed

Service Requested

Paging Replied

AuthenticationPending

AuthenticationCompleted

Authentication failed

AuthenticationRejected by UE

T3260 Expired (NoAuth. Response)

CC Setup sent

Call setup successful

(Alerting)

Call connected

CM Service Aborted

Disconnected at NAS

When possible, it identifies the

event that caused the outgoingcall setup failure. Otherwise it

shows the last event occurredbefore the failure

Iub_CallDropCause

Disconnected at NASlevel,

Disconnected atTransport Level

See Iu_CallDropped for triggers


14/32




Iub_CSCallState

RRC Released

Servi ce Requested

Paging Replied

Authentication

Pending

Authentication

Completed


AuthenticationRejected by UE

T3260 Expired (No

Auth. Response)

CC Setup sent

Call setup successful(Alerting)

Call connected

CM Service Aborted

Disconnected at NAS

level

Disconnected at

Transport Level

RRC Setup

Handover to other Iub

Iub_CallDuration msec.

Call duration is calculated from

the CC:Connect ACK to the

moment the call is completed ordropped.

NOTE: Calls released/dropped

between Alerting and Call setuphave Call Duration = 0

Iub_TimeBetweenIRRC_REQandSETUP msec.

RRC Setup time 1.

It is calculated from the 1st

RRC

connection request to the RRCConnection Setup

Iub_TimeBetweenRRC_REQandCOMP msec.

RRC Setup time 2.It is calculated from the 1

stRRC

connection request to the RRCConnection Setup Complete

Iub_TimeBetweenRRC_REQandCallStart msec.

Call Setup time 2.

It is calculated from the 1st

RRC

connection request to theCC:Alerting message


15/32




CS Radio Bearers Iub attributes

Iub_CSRadioBearerSetupFail 1 (Event)CS Radio Bearer Setup Failure- See description of KPIs in sec.

2.3

Iub_CSRadioBearerSetupOK 1 (Event)

Successful CS Radio Bearer

Setup - See description of KPIsin sec. 2.3

Iub_CSRadioReleaseSetupFail 1 (Event)

CS Radio Bearer Release

Failure - See description ofKPIs in sec. 2.3

Iub_CSRadioBearerReleaseOK 1 (Event)Successful CS Radio Bearer

Release - See description of

KPIs in sec. 2.3

CS Mobility Management Iub attributes

Iub_LocationUpdateOK 1 (Event)

Successful LAU

See descript ion of KPIs in sec.2.4

Iub_LocationUpdateFail 1 (Event)

Unsuccessful LAU


2.4

Iub_IMSIAttachOK 1 (Event)

Successful IMSI Attach


2.4

Iub_IMSIAttachFail 1 (Event)Unsuccessful IMSI AttachSee description of KPIs in sec.

2.4

Iub_CS_IMSIDetach 1 (Event)

IMSI Detach


Iub_LocationUpdateDuration msec.

Duration of LU procedure.

It is set only for successfulLocation Updates:

TimeLU_Accept TimeLU_Req

Or

TimeTMSI_ReallComp TimeLU_Req

depending on TMSI reallocation

Iub generic attributes

Iub_CS_Call_Type

Not defined, Voice,

Video, LocationUpdate, SMS, IMSIAttach, IMSI Detach

CM service Request

(Emergency call only), SMSsignaling, CC:Setup


16/32




Iub_Active_SetCount Long

Number of Radio links in the

Active Set.The attribute is based on the

RRC:Active Set Update

signaling and there is no

discrimination between Soft andSofter Handovers

Iub_Connection_ID LongIdentifies an AAL2 connection

over the Iub, based on thetriplet VPI-VCI-CID

Iub_Call_Id Long

Iu_Call_Id uniquely identifies an

RRC connection over the Iubinterface within a logfile. The

attribute is relevant for signalingmessages only (RRC and L3,NBAP, ALCAP)

Used to extract the signalling of

a call over Iub

Iub_Call_Id_Inc_UserPlane Long

Iub_Call_Id_Inc_UserPlane

uniquely identifies an RRC

connection and the associated

User plane connections overthe Iub interface within a logfile.

Used to extract the signaling

(RRC and L3, NBAP, ALCAP)and User Plane of a call over

Iub.

IubIu_Call_Id Long IubIu_Call_Id uniquely identifies

a connection across Iub and Iu

interfaces. The attribute is

relevant for signaling messagesonly (NBAP, ALCAP, RRC,

NAS, SCCP, RANAP)

NOTE: If the UE has SCCP

connections on both Iu-CS andIu-PS interfaces then two

different IubIu_Call_Id will beallocated

Used to extract the signalingand User plane of a call over Iuand Iub


17/32




IubIu_Call_Id_Inc_UserPlane Long IubIu_Call_Id_Inc_UserPlane

uniquely identifies a connectionover Iu and Iub interface,including user plane data.

NOTE: If the UE has SCCP

connections on both Iu-CS andIu-PS interfaces then two

differentIubIu_Call_Id_Inc_UserPlanewill be allocated

Used to extract the signaling

and User plane of a call over Iuand Iub

NOTE: User Plane over Iu-CSinterface is not tracked

Iub L2 attributes (Frame protocol MAC RLC)

UPFP_TFITransport Format Indicator

Protocol: FP

UPFP_QualityEstimate Quality Estimate field

Protocol: DCH FP

UPFP_CRCIndicatorCRC Indicator

Protocol: FP (UL only)

UPFP_ChanType Logical channel number

Protocol: RLCUPFP_AMD_SequenceNumber_UL[ ] Array of Uplink AM PDU

sequence numbers sent in oneTTI

Protocol: RLC

UPFP_AMD_SequenceNumber_DL[ ] Array of Downlink AM PDU


Protocol: RLC

UPFP_UMD_SequenceNumber_UL[ ] Array of Uplink UM PDU


Protocol: RLC

UPFP_UMD_SequenceNumber_DL[ ] Array of Downlink UM PDU


Protocol: RLC

UPFP_PollingBit Polling bit for AM RLC PDUs

Protocol: RLC

UPFP_ControlType Type of RLc Control PDU

Protocol: RLC


18/32




UPFP_FrameProtBler

Iub_FP_SUFI_Type SUFI type of for RLC PDU

Protocol: RLC

Iub_FP_SUFI_MRW_SN

Iub_FP_SUFI_MRW_N

Iub_FP_SUFI_LIST_SN

Iub_FP_SUFI_LIST_L

Iub_FP_SUFI_BITMAP

Iub_FP_SUFI_CW

Iub_FP_SUFI_LSN Last sequence number

acknowledged

Protocol: RLC

Iub_FP_SUFI_WSN

Iub_FP_SUFI_FSN

Iub_FP_SUFI_SN_ACK


19/32



3 PS Events

Events in the PS domain are referred to services like Web Browsing, File download, VideoStreaming, MMS, Session Management procedures (PDP Context Activation/Deactivation) andMobility Management procedures (PS Attach, Routing Area Update, PS Detach).

It should be noted that the PS event diagrams on Iub do not handle events in the applicationlayer (e.g. FTP, HTTP). From the radio technology point of view, all these application servicesrely on underlying Packet Calls.

There could be more than one definition of Packet Call over the Iub interface. For example, aPacket Call can be considered equivalent to a PDP Session or to PS RB Session; in thefollowing sections the definition of packet calls over the Iub interface adopted by Actix isdescribed.

Current Iub diagrams handle these main procedures/services:

PS MOC (Packet Switch Mobile Originated Call)

PS MTC (Packet Switch Mobile Terminated Call)

PDP Context Activation/Deactivation

Routing Area Updates

PS Attach/Detach

3.1 Iub PS Call Diagram


20/32



Unlike CS call handling, only one diagram traces PS Calls.

Definition of PS call over the Iub Interface:

A PS call is equivalent to a PS RB instance, provided that physical resources associatedwith the RB have been assigned at least once during the RB lifetime. It is possible for thenetwork to establish a PS RB without actually assigning any physical resource (Channelizationcode) to the mobile for that data connection. This is not considered a PS call. If later on thenetwork reconfigures the RB and assigns an underlying physical resource, then the eventengine will recognize it as a PS call.

A PS call does not necessarily starts at the RB Setup RRC procedure. Whenever it is possibleto derive from the signaling that an attempt to establish a PS call is ongoing, even before the RBsetup phase, an attempt of establishing a PS call is detected by the diagram. For example, aService Request message with service type Data implies that a RB and the associatedphysical resources need to be established to transfer data for the new service requested.

Details on the triggers for PS Calls related events are provided below in the KPIs description.

- PS Call Setup Failure (Iub_OutgoingCallSetupFail_PS, Iub_IncomingCallSetupFail_PS)

For PS connections initiated with a Service Requestwith Service Type different fromSignaling:

o Service Reject

o Release of the underlying transport layer (RRC Connection or PS Signalingconnection) at anytime between Service Requestand RB Setup

For any PS connection:

o RB Setup failure, regardless of the dedicated physical resources requested in the RBSetup message.

o Activation PDP Context Reject(if not due to RB Setup failure see above trigger)

o Release of the underlying transport layer (RRC Connection or PS Signalingconnection) at anytime between RB Setup and successful completion of the CallSetup (RB setup completeorActivation PDP Context Accept)

- PS Call Setup Successful (Iub_OutgoingCallOK_PS, Iub_IncomingCallOK_PS)

o RB Setup Complete if:

The PS Radio Bearer has physical resources allocated (it is possible to setup a PSRB without actually allocated any physical resource. This procedure is typicallyfollowed by a reconfiguration, which assigns the physical resources)

and

the RB Setup procedure is not part of a PDP Context Activation (the PDP Contextis already established - this is a typical scenario in always-on network)

o RB/Transport Channel Reconfiguration Complete for PS Radio Bearers previously setup without physical resources. The reconfiguration will have to allocate dedicatedphysical resources to the Radio Bearer


21/32



o Activation PDP Context Acceptif the associated PS Radio Bearer has physicalresources allocated

- PS Call Dropped (Iub_CallDropped_PS)

A call drop event can be set only if the call reached the Successful Call setup state.

o RRC Release with a release cause different from Normal Release or UserInactivity or Directed Signaling Connection Re-establishment

o PS Signaling Connection Release

o Any abnormal release of the underlying transport layer, i.e. without RRCConnection/PS Connection Release

o

PDP Context Deactivation Requestwith cause different from Regular Deactivation

- PS Call Completed (Iub_CallCompleted_PS)

o RRC Release with any of the following release causes:

Directed Signaling Connection Re-establishment

User Inactivity

Normal release

o PDP Context Deactivation Requestwith cause Regular Deactivation

o Detach Request

- Call Handed Over to other Iub (Iub_CallHandedOverToOtherIub)

See the description in the CS Mobile Originated call section

- PS Call switched to Cell_FACH state (Iub_CallSwitchedToCellFACH)

o RB / Transport Channel / Physical Channel Reconfiguration with RRC state indicatorset to Cell_FACH


22/32



3.2 PS_Radio_Bearer_Hand ling diagram

The scope of the Iub PS Radio Bearer Handling diagram is to trace the behavior of PS RadioBearers. Here below is shown the criteria used for the main PS RB KPIs:

- RB setup Failure (Iub_PSRadioBearerSetupFail)

Precondition is the detection of a previous RRC: Radio Bearer Setup message in the PSdomain;

o RRC: Radio Bearer Setup Failure

o Release of the underlying transport layer (RRC Connection) anytime between RRC:Radio Bearer Setup and RRC: Radio Bearer Setup Complete

- Successful RB setup (Iub_PSRadioBearerSetupOK)

Precondition is the detection of a previous RRC: Radio Bearer Setup message in the PSdomain;

o RRC: Radio Bearer Setup Complete

- RB Release Failure (Iub_PSRadioReleaseSetupFail)

Precondition is the detection of a previous RRC: Radio Bearer Release message in the PSdomain;

o RRC: Radio Release Setup Failure


23/32



o Release of the underlying transport layer (RRC Connection) anytime between RRC:Radio Bearer Release and RRC: Radio Bearer Setup Complete

- Successful RB release (Iub_PSRadioBearerReleaseOK)

Precondition is the detection of a previous RRC: Radio Bearer Release message in the PSdomain;

o RRC: Radio Bearer Release Complete

- PS Reconfiguration Failure (Iub_PSReconfFail)

Precondition is the detection of a previous reconfiguration request in the PS domain (RRC:Radio Bearer Reconf. / Transport Channel reconf. / Physical Channel Reconf.) ;

o

RRC: Radio Bearer / Transport channel / Physical Channel Reconfiguration Failureo Release of the underlying transport layer (RRC Connection) anytime between the

Reconfiguration request and the corresponding Complete message

- Successful PS Reconfiguration (Iub_PSReconfOK)

Precondition is the detection of a previous reconfiguration request in the PS domain (RRC:Radio Bearer Reconf. / Transport Channel reconf. / Physical Channel Reconf.) ;

o RRC: Radio Bearer / Transport channel / Physical Channel Reconfiguration Complete

3.3 Iub_UMTS_SM diag ram


24/32



The scope of the Iub UMTS SM Diagram is to trace on the Iub interface the SessionManagement activity of users (SM).

Here below is shown the criteria used for the main Iub Session Management KPIs:

- PDP Context Activation Failure (Iub_PS_PDPAct_From_UE_Fail,Iub_PS_PDPAct_From_NW_Fail)

The following scenarios trigger PDP Context Activation failure (precondition is thedetection of a previous SM:Activate PDP Context Requestmessage):

o SM:Activate PDP Context Reject

o T3385 expiry

o Release of the underlying transport layer (RRC / PS Signaling Connection) at anytimebetween SM:Activate PDP Context Requestand SM:Activate PDP Context Accept

The difference between the two KPIs is in the entity that requested the activation of thePDP context, UE (From_UE) or Network (From_NW).

- Successful PDP Context Activation (Iub_PS_PDPAct_From_UE_OK,Iub_PS_PDPAct_From_NW_OK)

The following scenarios trigger PDP Context Activation failure (precondition is thedetection of a previous SM:Activate PDP Context Requestmessage):

o SM:Activate PDP Context Accept

The difference between the two KPIs is in the entity that requested the activation of the PDPcontext, UE (From_UE) or Network (From_NW).

- PDP Context Deactivation Failure (Iub_PS_PDPDeact_From_UE_Fail,Iub_PS_PDPDeact_From_NW_Fail)

The following scenarios trigger PDP Context Deactivation failure (precondition is thedetection of a previous SM:Deactivate PDP Context Requestmessage):

o SM:Deactivate PDP Context Reject

o T3395 expiry

o Release of the underlying transport layer (RRC / PS Signaling Connection) at anytimebetween SM:Deactivate PDP Context Requestand SM:Deactivate PDP ContextAccept

- Successful PDP Context Activation (Iub_PS_PDPDeact_From_UE_OK,

Iub_PS_PDPDeact_From_NW_OK)

The following scenarios trigger PDP Context Deactivation failure (precondition is thedetection of a previous SM:Deactivate PDP Context Requestmessage):

o SM:Deactivate PDP Context Accept


25/32



The difference between the two KPIs is in the entity that requested the deactivation of thePDP context, UE (From_UE) or Network (From_NW).

3.4 Iub_UMTS_GMM diagram

The scope of the Iub UMTS GMM Diagram is to trace on the Iub interface the MobilityManagement activity of users PS domain (GMM).

Here below is shown the criteria used for the main Iub PS Mobility Management KPIs:

- PS Attach Failure (Iub_PS_Attach_Fail)

The following scenarios trigger PS Attach failure (precondition is the detection of aprevious Attach Request message):

o GMM:Attach Reject

o Release of the underlying transport layer (RRC / PS Signaling Connection) at anytimebetween GMM:Attach Requestand:

GMM:Attach Accept if this message does not include new P-TMSI

GMM:TMSI Reallocation Complete if Attach Accept message includednew P-TMSI

o T3350 expiry


26/32



- Successful PS attach (Iub_PS_Attach_OK)

The following scenarios trigger a successful PS Attach - precondition is the detection ofa previous Attach Request message:

o GMM:Attach Acceptif this message does not include new P-TMSI

o GMM:P-TMSI Reallocation Complete if Attach Accept message included new P-TMSI

- Routing Area Update Failure (Iub_PS_RAU_Fail)

The following scenarios trigger RAU failure (precondition is the detection of a previousRAU Request message):

o GMM:Routing Area Update Reject

o Release of the underlying transport layer (RRC / PS Signaling Connection) at anytimebetween 1

stRAU Requestattempt and:

GMM:RAU Acceptif this message does not include new P-TMSI

GMM:P-TMSI Reallocation Complete if RAU Accept message includednew P-TMSI

o T3350 expiry

- Successful Routing Area Update (Iub_PS_RAU_OK)

The following scenarios trigger a successful Routing Area Update - precondition is the

detection of a previous RAU Request message:o GMM:Routing Area Update Acceptif this message does not include new P-TMSI

o GMM:P-TMSI Reallocation Complete if RAU Accept message included new P-TMSI

- PS Detach Failure (Iub_PS_Detach_Fail)

The following scenarios trigger a PS Detach failure - precondition is the detection of aprevious GMM: Detach Request message:

o T3321 expiry

o Release of the underlying transport layer (RRC / PS Signaling Connection) at anytime

between 1st

Detach Requestattempt and Detach Acceptwhen the Detach is UEinitiated

- Successful PS Detach (Iub_PS_Detach_OK)

The following scenarios trigger a successful PS Detach - precondition is the detection ofa previous GMM: Request message:

o GMM:Detach Acceptmessage in case of UE initiated Detach

o The GMM: Detach Requestmessage itself in case of Network initiated Detach


27/32



3.5 Att r ib utes for Iub PS Call Handling


PS Calls attributes

Iub_OutgoingCallOK_PS 1 (Event)Successful PS MO Call Setup

See description of KPIs in sec. 3.2

Iub_OutgoingCallSetupFail_PS 1 (Event)PS MO Call Setup failure


Iub_IncomingCallOK_PS 1 (Event)Successful PS MT Call Setup


Iub_IncomingCallSetupFail_PS 1 (Event)PS MT Call Setup failure


Iub_CallCompleted_PS 1 (Event)

Successful PS Call Completion. Note

there is no distinction between MOC

and MTC.


Iub_CallDropped_PS 1 (Event)

PS Call dropped. Note there is no

distinction between MOC and MTC.


Call Handed Over to other Iub 1 (Event)Same event used in CS domain (seedescription in sec. 2.2 )

Iub_CallSwitchedToCellFACH 1 (Event)

The network switched the user to

Cell_FACH state.See description of KPIs in sec. 3.2


28/32




Iub_PSCallState

RRC Released

Service Requested

Paging Replied

Authentication Pending

Authentication Completed


Authentication Rejected byUE

T3360 Expired (No Auth.

Response)

PDP Act. Pending

PDP Act.CompletePDP Act. Rejected

PS RB Setup ongoing

RB Setup completed

RB setup failed

Channel Reconf.

RB Release

Channel Reconf.Complete

Channel Reconf.Failed

Service rejected

Call Setup FailedCall Released

Call Dropped

RRC Setup

Switched to Cell_FACH state

Handover to other Iub

It keeps track of the Iub call

sequence of a PS call

PS_Background

RRC Request.

NOTE: interactive, streaming,

conversational type of calls can

occur in both CS and PS domain,

therefore it is possible to set the PS

call type at the RRC ConnectionRequest only for the Background

case (apart from GMM-relatedcauses)

PS_Interactive

PS_Streaming

PS_Conversational

Activate PDP Context Accept (Trafficclass)

PS Registration (Attach/RAU)GMM:Attach Request

GMM:RAU Request

Iub_PS_Call_Type

PS Detach GMM: Detach Indication


29/32




PS Radio Bearers Iub attributes

Iub_PSRadioBearerSetupFail 1 (Event) PS Radio Bearer Setup Failure - Seedescription of KPIs in sec. 3.2

Iub_PSRadioBearerSetupOK 1 (Event)Successful PS Radio Bearer Setup -See description of KPIs in sec. 3.2

Iub_PSRadioReleaseSetupFai

l1 (Event)

PS Radio Bearer Release Failure -


Iub_PSRadioBearerReleaseO

K1 (Event)

Successful PS Radio Bearer

Release - See description of KPIs insec. 3.2

Iub_PSReconfFail 1 (Event)PS Reconfiguration Failure - Seedescription of KPIs in sec. 3.2

Iub_PSReconfOK 1 (Event) Successful PS Reconfiguration - Seedescription of KPIs in sec. 3.2

Iub_PS_AllocatedRated

No RB

No Physical Channel

8 kbps

16 kbps

32 kbps

64 kbps

128 kbps

256 kbps

384 kbps

This is the maximum user data rate

allocated for a specific PS RBconfiguration. The value is normally

changed via a

setup/release/reconfigurationprocedure

Iub_PS_RateDuration msec.The time a certain PS rate isallocated for

PDP attributes

Iub_PS_PDPAct_From_UE_O

K1 (Event)

Successful PDP Context Activationinitiated by UE


Iub_PS_PDPAct_From_NW_OK

1 (Event)

Successful PDP Context Activationinitiated by network


Succ_1_Attempt..

Succ_5_Attempt

In case of a successful PDP Context

Activation, it indicates the number ofActivate PDP Context Request

messages sent, within the sameRRC Connection

Rejected SM: Activate PDP Context Reject

Iub_PS_PDPAct_From_UE,

Iub_PS_PDPAct_From_NW

AbortedT3385 expiry of or release ofunderlying radio connection

Iub_PS_PDPAct_From_UE_F

ail1 (Event)

Failure in PDP Context Activationinitiated by UE



30/32




Iub_PS_PDPAct_From_NW_F

ail 1 (Event)

Failure in PDP Context Activation

initiated by networkSee description of KPIs in sec. 3.3

Iub_PS_PDPDeact_From_UE

_OK1 (Event)

Successful PDP ContextDeactivation initiated by UE


Iub_PS_PDPDeact_From_NW_OK

1 (Event)

Successful PDP ContextDeactivation initiated by network


Succ_1_Attempt

..

Succ_5_Attempt

In case of a successful PDP Context

Deactivation, it indicates the number

of Deactivate PDP Context Request

messages sent, within the sameRRC Connection

Rejected SM: Deactivate PDP Context Reject

Iub_PS_PDPDeact_From_UE,Iub_PS_PDPDeact_From_NW

AbortedT3395 expiry of or release ofunderlying radio connection

Iub_TimeBetweenPDP_ReqAndAct

msec.TimeAtcDPAcc - TimeActDPReq

Iub_TimeBetweenPDP_ReqA

ndDeActReqmsec.

TimeDeaPDPReq - TimeActPDPReq

Iub_TimeBetweenPDP_Deact

ReqAndDeActmsec.

TimeDeaPDPAcc TimeDeaPDPReq

Iu-PS Mobility Management attributesSucc_1_Attempt

..

Succ_5_Attempt

In case of a successful PS Attach, itindicates the number of Attach

Request messages sent, within thesame RRC Connection

Rejected GMM: Attach RejectIub_PS_Attach

AbortedT3350 expiry or release ofunderlying radio connection

Iub_PS_Attach_OK 1 (Event)Successful PS Attach


Iub_PS_Attach_Fail 1 (Event)Unsuccessful PS Attach


Iub_PS_Attach_Duration msec.

Duration of PS Attach procedure.

It is set only for successful PS

Attach:

TimeAtt_Accept TimeAtt_Req

Or

TimeAtt_Comp TimeAttt_Req

depending on P-TMSI reallocation


31/32




Succ_1_Attempt

..Succ_5_Attempt

In case of a successful RAU, it

indicates the number of RAURequest messages sent, within thesame RRC connection

Rejected GMM: RAU RejectIub_PS_RAU

AbortedT3350 expiry or release ofunderlying radio connection

Iub_PS_RAU_OK 1 (Event)Successful Routing Area Update


Iub_PS_RAU_Fail 1 (Event)Unsuccessful Routing Area Update


Iub_PS_RAU_Duration msec.

Duration of RAU procedure.

It is set only for successful RAU:

TimeRAU_Accept TimeRAU_Req

Or

TimeRAU_Comp TimeRAU_Req

depending on P-TMSI reallocation

Iub_PS_DetachSucc_1_Attempt

..

Succ_5_Attempt

In case of a successful Detach, it

indicates the number of Detach

Indication messages sent, within the

same RRC connection. This isapplicable only for UE initiated PS

Detach

Iub_PS_Detach_OK 1 (Event) Successful PS DetachSee description of KPIs in sec. 3.4

Iub_PS_Detach_Fail 1 (Event)Unsuccessful PS Detach



32/32



4 Overview of Iub Call tracking feature

Iub Call tracking allows to extract the messages (both signaling and user plane) for a particularcall from an Iub trace, which typically present interleaved traffic from different calls.

The benefit is being able to isolate the messages of interest for specific connections from theoften-confusing view of an Iub trace.

The following are the scenarios covered by the Call Tracking over Iub:

All the calls that include the RRC Connection Setup phase

Soft/Softer Handover tracking; Soft Handover tracking provided that the relevant Iubsare monitored in the same logfile

Calls in Cell_DCH state only

Notes:- If the user moves hand over to a NodeB whose Iub interface is not monitored in the

logfile, the call tracking algorithm set the final status of the call to Handed Over to otherIub

- If the user moves to Cell_FACH state the call tracking algorithm set the final status of thecall to UE switched to Cell_FACH

- A user starting a call in a NodeB whose Iub interface is not monitored in the logfile andthen handing over to the monitored Iub will be normally tracked

- A user performing a Cell_FACH to Cell_DCH transition will be tracked from the momentthe transition is completed

- The call tracking algorithm needs to know the mapping between VPI+VCI andAAL2 Path Id. The mapping is derived by the information transmitted in the RRCConnection Setup phase, using ALCAP and NBAP information elements. If anAAL2 connection is used for purposes other than the RRC Connection Setup (eg.Soft Handover RL Setup or Cell_FACh to Cell_DCH transition) and the Path IDwhere this AAL2 connection is setup is not in the mapping table then the traffic onthe AAL2 connection is not tracked.

While this limitation does not create issues in a live network log (where thenumber of RRC connections established is very high), it may affect analysis oflogs taken in more controlled environment like lab tests.

Attributes related to Iub Call Tracking

Iub_Call_Id: only the L3 signaling messages of the call are assigned a value

Iub_Call_Id_Inc_UserPlane: all the traffic (signaling, user data, RLC PDUs and most of theFrame Protocol messages) is assigned a value

IubIu_Call_Id, IubIu_Call_Id_Inc_UserPlane are used in the same way whenever a logfile

includes both Iub and Iu interface traces.

Iub Events Definition in UMTS-Unify3G v1_0

Documents

Transcript of Iub Events Definition in UMTS-Unify3G v1_0