Multiservice Switching Forum Contribution

msf2011.086.05

of 68

Multiservice Switching Forum Contribution Contribution Number: msf2011.086.05 Last Saved: 03/26/2013 16:03 PM Working Group: Interoperability and Test Title: MSF VoLTE testcases for Scenario 1a (Merged) Source: MSF

Abstract:

This document describes the test cases to test the interoperability between key components of the EPS/LTE architecture. The interfaces to be tested are specified (in terms of references to the appropriate 3GPP specifications) within this document such that additional implementation agreements for the individual interfaces need not be created.

The test cases in this document have been prepared by GENBAND, Vodafone, and ZTE, and are intended to provide a baseline for the VoLTE test cases in subsequent scenarios. This version includes input from the MSF Q3 meeting. Changes have been accepted to provide a clean version.

By submitting this contribution, the representative(s) of the source company(ies) acknowledge reading and agrees to the MSF IPR Policy Statement. The Multiservice Switching Forum (MSF) is responsible for developing Implementation Agreements or Architectural Frameworks which can be used by developers and network operators to ensure interoperability between components from different vendors. MSF Implementation Agreements are formally ratified via a Straw Ballot and then a Principal Member Ballot. Draft MSF Implementation Agreements or Architectural Framework may be published before formal ratification via Straw or Principal Member Ballot. In order for this to take place, the MSF Technical Committee must formally agree that a draft Implementation Agreement or Architectural Framework should be progressed through the balloting process. A Draft MSF Implementation Agreement or Architectural Framework is given a document number in the same manner as an Implementation Agreement. Draft Implementation Agreements may be revised before or during the full balloting process. The revised document is allocated a new major or minor number and is published. The original Draft Implementation Agreement or Architectural Framework remains published until the Technical Committee votes to withdraw it. After being ratified by a Principal Member Ballot, the Draft Implementation Agreement or Architectural Framework becomes final. Earlier Draft Implementation Agreements or Architectural Frameworks remain published until the Technical Committee votes to withdraw them.

msf2011.086.05

of 68

DISCLAIMER The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and the Multiservice Switching Forum is not responsible for any errors or omissions. The Multiservice Switching Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither the Multiservice Switching Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind whether based on theories of tort, contract, strict liability or otherwise, shall be assumed or incurred by the Multiservice Switching Forum, its member companies, or the publisher as a result of reliance or use by any party upon any information contained in this publication. All liability for any implied or express warranty of merchantability or fitness for a particular purpose is hereby disclaimed. The receipt or any use of this document or its contents does not in any way create by implication or otherwise:

Any express or implied license or right to or under any Multiservice Switching Forum member company’s patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor Any warranty or representation that any Multiservice Switching Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor Any commitment by a Multiservice Switching Forum company to purchase or otherwise procure any product(s) and/or service(s) that embody any or all of the ideas, technologies, or concepts contained herein; nor Any form of relationship between any Multiservice Switching Forum member companies and the recipient or user of this document.

Implementation or use of specific Multiservice Switching Forum Implementation Agreements, Architectural Frameworks or recommendations and Multiservice Switching Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in the Multiservice Switching Forum. For addition information contact: Multiservice Switching Forum 39355 California Street, Suite 307, Fremont, CA 94538 (510) 608-5922 (510) 608-5917 (fax) [email protected] WWW.MSFORUM.ORG © Multiservice Switching Forum 2009

msf2011.086.05

of 68

Table of Contents

MULTISERVICE SWITCHING FORUM CONTRIBUTION .......................................................... 1

1 SCOPE .............................................................................................................................................. 5

2 REFERENCES ................................................................................................................................. 5

3 NETWORK CONFIGURATION .................................................................................................. 5

3.1 TEST CONFIGURATION ................................................................................................................ 5

4 SCENARIO 1 TEST CASES – BASIC INTEROPERABILITY ................................................ 5

4.1 SCENARIO 1A – VOLTE .............................................................................................................. 5 4.1.1 S1a-1 - UE Initial Attach with default bearer establishment and IMS SIP registration. .. 6 4.1.2 S1a-2 – Tracking Area Update. ......................................................................................... 9 4.1.3 S1a-3 –LTE UE Detach (IP-CAN Session Tear Down) ..................................................... 9 4.1.4 S1a-4 – IMS UA Registration(via LTE UE) ..................................................................... 11 4.1.5 S1a-5 - UE Initiated IMS call setup. ................................................................................ 11 4.1.6 S1a-3 - UE Initiated IMS call termination. ...................................................................... 16 4.1.7 S1a-7 - Authentication for Ut Configuration (3GPP TS 24.623) .................................... 18 4.1.8 S1a-8 – Service Configuration over Ut ............................................................................ 21 4.1.9 S1a-9 - Originating Identification Presentation ( 3GPP TS 24.607) .............................. 21 4.1.10 S1a-10 - Originating Identification Restriction (3GPP TS 24.607) ................................ 23 4.1.11 S1a-11 – Service Configuration over Ut of TIP/TIR ....................................................... 25 4.1.12 S1a-12 - Terminating Identification Presentation (3GPP TS 24.608) ............................ 25 4.1.13 S1a-13 - Terminating Identification Restriction (3GPP 24.608) .................................... 28 4.1.14 S1a-14 Service Configuration over Ut of CDIV (Communication Forwarding Unconditional) ................................................................................................................................. 30 4.1.15 S1a-15 - Communication Forwarding Unconditional (3GPP TS 24.604) ...................... 33 4.1.16 S1a-16 – Communication Forwarding on not Logged in (3GPP TS 24.604) ................. 37 4.1.17 S1a-17 - Communication Forwarding on Busy (3GPP TS 24.604) ................................ 40 4.1.18 S1a-18 - Communication Forwarding on not Reachable (3GPP TS 24.604) ................. 43 4.1.19 S1a-19 - Communication Forwarding on No Reply ........................................................ 47 4.1.20 S1a-20 – Communication Barring of All Incoming Calls (3GPP TS 24.611) ................. 51 4.1.21 S1a-21 – Communication Barring of All Outgoing Calls (3GPP TS 24.611) ................. 53 4.1.22 S1a-22 – Communication Barring of Outgoing International Calls (3GPP TS 24.611) 55 4.1.23 S1a-23 - Barring of Outgoing International Calls – ex Home Country (3GPP TS 24.611) 56 4.1.24 S1a-24 - Barring of Incoming Calls – When Roaming (3GPP TS 24.611) ..................... 57 4.1.25 S1a-25 - Communication Hold (3GPP TS 24.610) .......................................................... 58 4.1.26 S1a-26 - Message Waiting Indication (3GPP TS 24.606) ............................................... 60 4.1.27 S1a-27- UE-based Communication Waiting ( 3GPP TS 24.615) .................................... 62 4.1.28 S1a-28 Ad-Hoc Multi Party Conference (3GPP TS 24.605) ........................................... 65

ANNEX ABBREVIATIONS ................................................................................................................. 68

Table of Figures

Figure 1 - Scenario 1a - Basic Configuration ............................................................................................ 6 Figure 2 – UE Initial Attach with default bearer establishment and IMS SIP Registration ...................... 7 Figure 3 – UE IMS SIP Registration details .............................................................................................. 8 Figure 4 – S1a-3 - UE detach ................................................................................................................... 10 Figure 5 – S1a-3 - UE SIP deregistration ................................................................................................ 11 Figure 6 – S1a-2 - UE initiated IMS call – focus IMS ............................................................................ 12 Figure 7 – S1a-2 - UE initiated IMS call – complete .............................................................................. 13 Figure 8 – UE initiated IMS call – IMS details ....................................................................................... 14 Figure 9 – UE initiated IMS call termination .......................................................................................... 17

msf2011.086.05

of 68

Figure 10 – UE initiated IMS call termination – IMS details .................................................................. 17 Figure 11 – Originating Identification Restriction Message Flow .......................................................... 24 Figure 12 – Terminating Identification Presentation Message Flow ....................................................... 26 Figure 13 – Terminating Identification Restriction Message Flow ......................................................... 29 Figure 14 – Service Configuration over Ut of CDIV Message Flow ...................................................... 31 Figure 15 – Communication Diversion Unconditional Message Flow ................................................... 35 Figure 16 – Communication Forwarding on Not Logged in Message Flow ........................................... 38 Figure 17 – Communication Forwarding on Busy Message Flow .......................................................... 41 Figure 18 – Communication Forwarding on not Reachable Message Flow ............................................ 45 Figure 19 – Communication Forwarding on No Reply Message Flow ................................................... 49 Figure 20 – Barring of All Incoming Calls Message Flow ..................................................................... 52 Figure 21 – Barring of All Outgoing Calls Message Flow ..................................................................... 54 Figure 22 – Communication Hold Message Flow ................................................................................... 59 Figure 23 – Message Waiting Indication Message Flow ......................................................................... 61 Figure 24 – Communication Waiting Message Flow ............................................................................. 64 Figure 25 – Ad-Hoc Multi Party Conference Message Flow .................................................................. 66

msf2011.086.05

of 68

1 Scope This document describes a test plan for the MSF LTE interoperability test event. The testing targets the the 3GPP Release 9 Evolved Packet Core interfaces in order to demonstrate multi-vendor interoperability with specific scenarios defined within msf2010.111 " LTE Phase 2 Interoperability Event Testing Scenarios" [1]. The tests cover:-

• Basic Interoperability - VoLTE

o UE Attach/Detach

o Default Bearer Establishment

o IP-CAN Session establishment/tear down

o IMS UA Registration (via LTE UE)

o IMS Voice Session Establishment (LTE UE to LTE UE)

o IMS Voice Session Termination

o MMTel Supplementary Service Interaction and Configuration

2 References [1] msf2010.111 VoLTE Interoperability Event Testing Scenarios

3 Network Configuration The architecture of the network configuration for the testing is defined within msf2011.111 "VoLTE Interoperability Event Testing Scenarios" [1]. In addition, the network configuration diagram is detailed at the beginning of each Scenario under test.

3.1 Test Configuration • The provision of a suitable Diameter protocol analyser is required to monitor the Diameter

messages on the S6a, S6d, S9, Gx and Rx interfaces.

• The provision of a suitable GTP-Cv2 protocol analyser is required to monitor the GTP messages on the S3, S4, S5, S8, S10 and S11 interfaces.

• The provision of a suitable GTP-Uv1 protocol analyser is required to monitor the GTP messages on the S1-U, X2, S4, S5, S8, and S12 interfaces.

• The provision of a suitable S1AP protocol analyser is required to monitor the messages on the S1-MME interface.

• Provision of subscriber information is required in the HSS and within the 2G/3G/LTE SIM cards.

4 Scenario 1 Test Cases – Basic Interoperability

4.1 Scenario 1a – VoLTE The architecture for the Basic Interoperability test cases is shown in the figure below. The interfaces for which interoperability will be tested are shown in red (viz S1-MME, S1-U, S-11, S6a, S11, S5/S8, Rx, Gx, Mw, ISC and Ut interfaces). In all circumstances it will be necessary to interoperate multiple of the interfaces together rather than in isolation.

msf2011.086.05

of 68

IMS UA

MME

S-GW

HSS P-CSCF

P-GW

PCRF

UE

eNodeB

IMS Core

LTE-UuS11

S5

Gx

SGi

Rx

S6a

S1-MME

S1-U

IMS UA

UE

LTE-Uu

I/S-CSCF

MMTel ASSh

Mw

ISC

Cx

UtUt

Figure 1 - Scenario 1a - Basic Configuration

4.1.1 S1a-1 - UE Initial Attach with default bearer establishment and IMS SIP registration.

4.1.1.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a UE Initial Attach (default bearer Establishment), followed by an IMS SIP Registration.

4.1.1.2 Test Setup

4.1.1.2.1 Test Pre-conditions • Network configuration is as per Section 4.1.

• EPS Subscriber information for the UE attaching to the network is configured in the HSS MMTel AS and the PCRF.

• Display name of user is provisioned in HSS

• HSS subscriber profile contains an iFC to send Register requests to the MMTel AS.

• MMTel AS is in the trust domain

• Network Equipment configured as below:-

LTE UE eNodeB MME S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel AS

HSS

X X X X X X X X X X NOTE: The focus of this test case is S1-MME, S1-U, S6a, S11, S5/S8, Rx, Gx, Mw, ISC and Ut interfaces.

4.1.1.2.2 Procedure • Perform a UE Initial Attach to the LTE Radio Access and Evolved Packet Core.

• Perform a UE IMS SIP Registration

4.1.1.3 Observable Results The message flows for this test are documented in this section. Each test builds on the previous tests, adding additional capability on top of functionality that has already been verified in previous test cases. Therefore the message flows focus on the steps and parameters that are core to this test case. The message flows do not attempt to show every single parameter in message flows. In addition, the message flows do not in general illustrate optional parameters.

msf2011.086.05

of 68

This section also captures the pass/fail criteria for this test case. The pass / fail criteria do not consider optional parameters or functionality.

4.1.1.3.1 Message Flows The UE Attach message flow is shown below.

Note that the message flows/contents for may vary slightly based on the configuration used. UE IMSeNB MME S-GW PCRF

CCA-I

CCR-I

APN:.voice.tbd e; QCI:5; ARP{6,0,0}; APN AMBR:104k

IP@; QCI:5; ARP: {6,0,0}; APN AMBR:104k

QCI:5; ARP: {6,1,1}; APN AMBR:104k; IP default rule TFT

IP@; QCI:5; ARP: {6,1,1};

APN AMBR:104k

SIP traffic through “voice” default bearer

--- Ready for SIP calls ----

[ NAS PDU ][ EPS SM: PDN Connectivity Request ][ APN:.voice.tbd ]

Uplink NAS TransportCreate Session Request

Create Session Response

E-RAB SetupE-RAB Setup RequestQCI:5; ARP: {6,0,0}; UE AMBR:10Mbps/50Mbps

[ NAS PDU ][ Activate Default Bearer Request ][ APN:fixed.voice.vodafone.de; IP@; ][ QCI:5; APN AMBR:104k ]

RCC Reconfiguraton

RCC Connection Complete

[ NAS PDU ][ EPS SM: Activate Default Bearer Request ]

[ NAS PDU ] [ EPS SM: Activate Default Bearer Accept ]

E-RAB SetupE-RAB Setup Response

[ NAS PDU ][ Activate Default Bearer Accept ]

Uplink NAS Transport

SIP Register

SIP 401 Unauthorized + WWW-Authenticate

SIP Register + Authorization

SIP OK

P-GW

APN:.voice.tbd e; QCI:5; ARP{6,0,0}; APN AMBR:104k

Create Session Request

IP@; QCI:5; ARP: {6,1,1}; APN AMBR:104k

Create Session Response

RCC Connection Request

RCC Connection SetupTrigger:PIN entered

correctlyon the UE

RRC Connection Setup complete[ Dedicated NAS ][ Attach Request ]

Uplink Direct Transfer

Modify Bearer Request

Modify Bearer Response

Figure 2 – UE Initial Attach with default bearer establishment and IMS SIP Registration

msf2011.086.05

of 68

1. Register 2. Register

3. Cx - Query /Cx - Select - Pull

4. Cx - Query Resp/Cx - Select - Pull Resp

7 . Cx - Pu t Resp /Cx - Pull Resp

5 . Register

9 . 200 OK 10 . 200 OK

11 . 200 OK

6 . Cx - put /Cx - Pull

8 . Service Control

I-CSCF HSS S-CSCFP-CSCFUE

Figure 3 – UE IMS SIP Registration details

4.1.1.3.2 Pass/Fail criteria • Verify that the monitored message sequence is correct.

• Verify that the Attach Request message contains the following mandatory information elements (IE): EPS attach type, NAS key set identifier, Old GUTI or IMSI, UE network capability, ESM message container. The other optional IEs: Old P-TMSI signature, Additional GUTI, DRX parameter, MS network capability and TMSI status may be included too.

• Check that the MME sends NAS Security Mode Command (Selected NAS algorithms, eKSI, ME Identity request, UE Security Capability) message to the UE

• The UE responds NAS with Security Mode Complete (NAS-MAC, ME Identity) message

• Verify that the Create Session Request contains the APN for voice, QCI=5 and the ARP value

• Verify that within the CCA the PCRF sets the right values for ARP: {Priority-Level, Pre-emption-Capability, Pre-emption-Vulnerability} see 3GPP TS 29.212

• Verify that the Attach Accept message contains the following mandatory information elements (IE): EPS attach result, T3412 value, TAI list, ESM message container. The other optional IEs may be included too.

• Verify that the Attach Complete message contains the ESM message container IE.

• Verify that the The INITIAL CONTEXT SETUP REQUEST message contains the E-RAB to be Setup List IE, the ATTACH ACCEPT message on NAS level and the required optional IEs to establish a UE context in the eNB.

• Verify that the INITIAL CONTEXT SETUP RESPONSE message (step 19) contains the E-RAB Setup list of successfully established E-RABs.

msf2011.086.05

of 68

• Verify that ATTACH REQUEST, ATTACH ACCEPT and ATTACH COMPLETE messages are transported successfully on the S1-MME interface.

• Verify that the related EPS Bearers have been established, and that the UE has been issued with an IP Address.

• Verify that the UE initiates a SIP registration and is registered.

• Verify that the UE includes a P-Access-Network-Info built as follows:

1. access-type = (“3GPP-E-UTRAN-FDD” or “3GPP-E-UTRAN-TDD”) ; or access-class = (“3GPP-E-UTRAN”)

2. A "utran-cell-id-3gpp" parameter set to a concatenation of the MCC, MNC, TAC (as described in 3GPP TS 23.003 [3]) and the Cell Identity (as described in 3GPP TS 23.401 [7B]), obtained from lower layers of the UE, and is coded as a text string as follows:

a. Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), TAC (fixed length code of 16 bits using full hexadecimal representation) and Cell Identity (fixed length code of 28 bits using a full hexadecimal representation);

• Verify that the P-CSCF inserts a P-Visited-Network-ID header

• Verify that the P-Access-Network-Info and P-Visited-Network-ID headers are passed to the MMTel AS in the 3rd party REGISTER from the S-CSCF to the MMTel AS

• Verify that IMS-AKA authentication is used.

• Verify that the S-CSCF sends the user’s display name (received from HSS) in the P-Associated-URI header of the 200 OK for the Register.

4.1.1.4 Trace Capture The main focus of this test case is the interaction between the eNodeB - MME (S1-MME), the eNodeB – S-GW (S1-U), MME-HSS (S6a), S-GW-P-GW (S5), P-GW-PCRF (Rx) and UE-IMS., I-CSCF-HSS(Cx), S-CSCF-HSS (Cx), S-CSCF-P-CSCF (Gm), P-CSCF-UE (Gm). It is essential that traces of the messages exchanged on these interfaces be captured during the testing and validated against the message flow shown above.

4.1.1.5 Known Issues None.

4.1.2 S1a-2 – Tracking Area Update. This test case is covered in scenario 4 (Handover) since tracking area updates only occur in connected mode, and the UE typically performs the initial attach in idle mode.

4.1.3 S1a-3 –LTE UE Detach (IP-CAN Session Tear Down)

4.1.3.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a UE initiated call termination.

4.1.3.2 Test Setup


msf2011.086.05

of 68

• EPS Subscriber information for the UE attaching to the network is configured in the HSS MMTel AS and the PCRF.

• User is attached and IMS registered 4.1.2



P-GW PCRF

P-CSCF

I/S-CSCF

MMTel AS

HSS


4.1.3.2.2 Procedure • Switch off the terminal.

• Check if the UE is detached.

4.1.3.3 Observable Results

4.1.3.3.1 Message Flows The UE Detach message flow is shown below.

Note that the message flows/contents for may vary slightly based on the configuration used.

UE eNodeB MME S-GW P-GW PCRF

Detach Request

Detach Accept

Delete Session Request

Delete Session Response

PCEF Initiated IP-CAN Session Termination

UE Context Release Command

UE Context Release Complete

Delete Session Request

Delete Session Response

HSS

Notify Request

Notify Answer

IMS

IMS deregistration

Figure 4 – S1a-3 - UE detach

The IMS deregistration can also be done before actually detach the UE from the network. In this case the following SIP signalling will take place prior to the detach request.

msf2011.086.05

of 68

UE P-CSCF S-CSCF HSS

Service Control

REGISTER (expiration interval =0)

REGISTER (expiration interval =0)

SAR

SAA

200 ok

200 ok

Figure 5 – S1a-3 - UE SIP deregistration

4.1.3.3.2 Pass/Fail criteria • Verify that the monitored message sequence is correct and the mandatory parameters

are presenting the messages.

• Verify that the UE is detached in the HSS.

4.1.3.4 Trace Capture The main focus of this test case is the interaction between the UE-MME, MME-HSS, MME-S-GW and S-GW – P-GW/PCRF. It is essential that traces of the messages exchanged on these issues be captured during the testing and validated against the message flow shown above.


4.1.4 S1a-4 – IMS UA Registration(via LTE UE) Registration is included as a component of the initial UA attach in test S1a-1.

4.1.5 S1a-5 - UE Initiated IMS call setup.

4.1.5.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a UE initiated call setup.

4.1.5.2 Test Setup

4.1.5.2.1 Test Pre-conditions

msf2011.086.05

of 68

• Network configuration is as per Section 4.1.

• EPS Subscriber information for the UEs attaching to the network is configured in the HSS MMTel AS and the PCRF.

• LTE UE1 and LTE UE2 both have registered originating and registered terminating iFCs for SIP INVITE requests to the MMTel AS provisioned in their subscriber profile on the HSS.

• MMTel AS is in the trust domain.

• Both users are attached and IMS registered as in section 4.1.1



P-GW PCRF

P-CSCF

I/S-CSCF

MMTel AS

HSS


4.1.5.2.2 Procedure • LTE UE1 calls LTE UE2 by dialling the MSISDN based IMPU of LTE UE2.

• LTE UE2 answers the call.


4.1.5.3.1 Message Flows The call establishment message flow is shown below.

Note that the message flows/contents for may vary slightly based on the configuration used. UE SBC B2BeNB IMSMME/

SGWPGW PCRF

RTPRTP flow through dedicated bearer

< TFT, codec1 >

All RTCP messages are sent through default bearer

AAR

SIP Invite

SIP 100 Trying

SIP Invite

SIP 100 Trying

SIP 407 Proxy Auth. Required

SIP 200 OK

RTCP Sender Report

AAR

SIP ACK

RTCP Sender ReportSIP ACK

SIP 407 Proxy Authentication Required

SIP ACK

SIP Invite

SIP 100 Trying

SIP 180 Ringing

SIP 200 OK

AAR

AAA

AAA

AAA

<SDP, Access ip/port, codec 1, codec2>

< Proxy-Authenticate >

<SDP, Access ip/port, codec 1, codec2, Proxy-Authorization >

< SDP: B2B ip/port, codec2 >

< TFT, codec1 >

< SDP, B2B: Access ip/port, codec 1, codec2 >

< SDP: NGN ip/port, codec2 >< TFT, codec2 >

SIP ACK

SIP 180 Ringing

SIP Invite

<SDP, Access ip/port, codec 1, codec2, Proxy-Authorization >

SIP 100 Trying

Trigger: User initiates a call

Figure 6 – S1a-2 - UE initiated IMS call – focus IMS

msf2011.086.05

of 68

UE P-CSCFeNB IMSMME PGW PCRF


TFT, codec 1QCI:1; ARP: {7,1,0};

TFT, 88kbpsQCI:1; ARP:{7,1,0}; TFT, MBR&GBR 88kbps

All RTCP messages are sent through default bearer

QCI:1; ARP:{7,0,1};MBR&GBR 88kbps

[ IP@; QCI:1; ][ TFT; MBR&GBR 88kbps ]

E-RAB SetupE-RAB Setup Request

[Activate Dedicated Bearer Req]

E-RAB SetupE-RAB Setup Reponse

[ Activate Dedicated Bearer Res ]

Create Bearer Request

Create Bearer Response

RAR

RAA

AAR

AAA

SIP Invite

SIP 100 Trying

SIP Invite

SIP 100 Trying

SIP 180 Ringing

SIP 200 OK

RTCP Sender Report

AAR

SIP ACK

RTCP Sender Report

SIP ACK

RCC Reconfiguraton[ Activate Dedicated Bearer Request ]

[ Activate Dedicated Bearer Accept ]

SIP 407 Proxy Authentication Required + Proxy-Authenticate SIP ACK

SIP Invite + Proxy-Authorization

SIP 100 Trying

SIP 180 Ringing

SIP 200 OK

E-RAB ModifyE-RAB Modify Request

Update Bearer Response

RAAAAA

RAR

E-RAB ModifyE-RAB Modify Response

RCC Reconfiguraton

RCC Reconfiguraton Complete

[ Modify Bearer Req ]

[ Modify Bearer Res ]



E-RAB ModifyE-RAB Modify Request

Update Bearer Request

Update Bearer Response

RAAAAA

RAR

E-RAB ModifyE-RAB Modify Response

RCC Reconfiguraton [ Modify Bearer Req ]




AAR

SIP 407

SIP ACK

SIP Invite

SIP 100 Trying

Trigger: User initiates a call

S-GW

Update Bearer Request

Figure 7 – S1a-2 - UE initiated IMS call – complete

msf2011.086.05

of 68

P-CSCF UE

4. Invite (Initial SDP Offer)


8. Offer Response

18. Response Conf (Opt SDP)

21. Conf Ack (Opt SDP)



33. Reservation Conf




38. Ringing

Terminating Home Network


10. Offer Response11. Offer Response





42. 200 OK

55. ACK56. ACK

45. 200 OK46. 200 OK

39. Ringing40. Ringing

57. ACK

5. Service Control

S-CSCF

9. Authorize QoSResources

22. ResourceReservation

32. Alert User

27. Approval of QoSCommit 44. Start Media

43. Enabling of Media Flows

1. Invite (Initial SDP Offer) 2. Invite (Initial SDP Offer)

11. Offer Response






28 . Reservation Conf



41. Ringing

Originating Home Network


12. Offer Response

14. Offer Response



37. Reser vation Conf

47. 200 OK

52. ACK 53. ACK

48. 200 OK

50. 200 OK

42. Ringing 43. Ringing

54. ACK

13. Authorize QoS Resources

16. Resource Reservation

41. Alert User 49. Enabl ing of

Media Flows

51. Start Media

S-CSCFP-CSCFUE

3. Service Control


Figure 8 – UE initiated IMS call – IMS details


are presenting the messages as follows (Note: the list may not be complete).

UE: Verify the presence of the header fields according to 3GPP TS 22.249 Table A.46: Supported header fields within the INVITE request, for instance:

• what kind of security mechanism in use;

• From header field (if privacy is required, although for basic calls this should not be necessary);

• Contact header field;

• Route header field;

• Request-URI (SIP or tel URI)

• if a P-Preferred-Identity was included, check the public user identity;

• Supporting the preconditions mechanism (Supported header field, Require header field);

• Accept header field with "application/sdp";

UE: acknowledge the 200 (OK) response with an ACK request:

msf2011.086.05

of 68

P-CSCF: receiving INVITE request

• remove its own SIP URI from the top of the list of Route header fields;

• the resulting list of Route header fields matches the list of URIs received in the Service-Route header field;

• add its own address to the Via header field;

• add its own SIP URI to the Record-Route header field;

• remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert a P-Asserted-Identity header field;

• add a P-Charging-Vector header field;

• save the Contact, CSeq and Record-Route header field values;

• forward the request, based on the topmost Route header field.

P-CSCF: receiving 1xx or 2xx response to the INVITE request

• store the values received in the P-Charging-Function-Addresses header field;

• store the list of Record-Route header fields from the received response;

• store the dialog ID and associate it with the private user identity and public user identity involved in the session;

• save the Contact, From, To and Record-Route header field values received;

S-CSCF: receiving INVITE request (addition to what described in Subclauses 5.4.3.2 and 5.4.3.3 of 3GPP TS24.229)

• identify the user by the public user identity as received in the P-Asserted-Identity header field;

• challenge the user by generating a 407 (Proxy Authentication Required) response for the received request, if Proxy-Authorization header field was not included;

• If the request contains a Proxy-Authorization header field, check whether the Proxy-Authorization header field.

• examine the SDP offer (the "c=" parameter) to detect if it contains an IP address type or without examining the SDP;

• insert a P-Charging-Function-Addresses header field populated with values received from the HSS when receiving the 1xx or 2xx response

• Verify can hear audible ringback on LTE UE1

• Verify can hear station ringing on LTE UE2

• Verify that after call is answered speech path exists between LTE UE1 and LTE UE2

• Verify that the signalling path traverses the MMTel AS twice: once for the originating UE and once for the terminating UE.

• Verify that the AMR speech codec is being used.

• Verify that LTE UE1 includes a P-Access-Network-Info built as follows:

1. access-type = (“3GPP-E-UTRAN-FDD” or “3GPP-E-UTRAN-TDD”) ; or access-class = (“3GPP-E-UTRAN”)

2. A "utran-cell-id-3gpp" parameter set to a concatenation of the MCC, MNC, TAC (as described in 3GPP TS 23.003 [3]) and the Cell Identity (as described in 3GPP TS 23.401 [7B]), obtained from lower layers of the UE, and is coded as a text string as follows:

msf2011.086.05

of 68

a. Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), TAC (fixed length code of 16 bits using full hexadecimal representation) and Cell Identity (fixed length code of 28 bits using a full hexadecimal representation);

• Verify that the P-Access-Network-Info header is passed to the originating MMTel AS.

4.1.5.4 Trace Capture The main focus of this test case is the interaction between the UE-IMS, PCRF-SBC, SCSCF-MMTel-AS (ISC) and SBC-IMS. Further in scope is the reconfiguration of the established bearer triggered by SBC via the PCRF, P-GW, S-GW, MME and eNodeB all the way through to the UE. It is essential that traces of the messages exchanged on these interfaces be captured during the testing and validated against the message flow shown above.


4.1.6 S1a-3 - UE Initiated IMS call termination.

4.1.6.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a UE initiated call termination.

4.1.6.2 Test Setup





• User is attached and IMS registered and a call is ongoing as in section 4.1.5



P-GW PCRF

P-CSCF

I/S-CSCF

MMTel AS

HSS


4.1.6.2.2 Procedure • Perform a UE initiated call termination.

• Check if the call is terminated.


4.1.6.3.1 Message Flows The IMS session termination message flow is shown below.

msf2011.086.05

of 68

Note that the message flows/contents may vary slightly based on the configuration used.

UE P-CSCFeNB IMSMME P-GW PCRF

STR

SIP BYESIP BYE

SIP 200 OK

STA


SIP 200 OK

RAR

RAA

Delete Bearer RequestE-RAB ReleaseE-RABToBeRlsdLst

[ Deact. Bearer Request ]

E-RAB ReleaseE-RABRlsLstBrRelComp

Uplink NAS Transport

[ Deact. Bearer Accept ] Delete Bearer Response

Remove TFT rule

S-GW

Figure 9 – UE initiated IMS call termination

UE IP-CANUE

P-CSCF/

PCRF

Visited Network

14. Rls Response

12. SIP OK

IP-CAN

Visited Network

5. Bye

15. SIP OK 13. Release resource 16. SIP OK

S-CSCF

Home Network

1. Bye

7. Bye

17. SIP OK

4. Remove authorisation

6. Service Control

8. Service Control 9. Bye

11. Bye

3. Rls Response 2. Release resource

18. SIP OK

for bearer resources

10. Remove authorisationfor bearer resources

S-CSCFP-CSCF/PCRF

Figure 10 – UE initiated IMS call termination – IMS details

Note: the BYE and 200 OK will traverse the originating and terminating AS, although this is not explicitly shown on the above diagram.


are present in the messages.

• Verify that speech path no longer exists between LTE UE1 and LTE UE2.

msf2011.086.05

of 68

UE: BYE request

• Verify the presence of the header fields according to 3GPP TS 22.249 Table A.9: Supported header fields within the BYE request.

P-CSCF: generate a BYE request

• a Request-URI, set to the stored Contact header field provided by the called user;

• a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

• a From header field, set to the From header field value as received in the initial INVITE request;

• a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

• a CSeq header field, set to the current CSeq value stored for the direction from the calling to the called user, incremented by one;

• a Route header field, set to the routeing information towards the called user as stored for the dialog;

• send the generated BYE requests towards the called user.

S-CSCF: generate a BYE request

• a Request-URI, set to the stored Contact header field provided by the called user;

• a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

• a From header field, set to the From header field value as received in the initial INVITE request;

• a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

• a CSeq header field, set to the CSeq value that was stored for the direction from the calling to the called user, incremented by one;

• a Route header field, set to the routeing information towards the called user as stored for the dialog;

• a Reason header field that contains proper SIP response code. (Note: a reason header is not inserted by the S for normal call takedown.)

4.1.6.4 Trace Capture The main focus of this test case is the interaction between the UE-IMS, PCRF-SBC and SBC-IMS. Further in scope is the deletion of the dedicated bearer triggered by SBC via the PCRF, P-GW, S-GW, and MME all the way through to the eNodeB. It is essential that traces of the messages exchanged on these interfaces be captured during the testing and validated against the message flow shown above.


4.1.7 S1a-7 - Authentication for Ut Configuration (3GPP TS 24.623)

4.1.7.1 Purpose This test case validates that the client can be authenticated over the Ut interface. Based on 3GPP TS 24.623 release 9 version 9.2.0. The focus of this test case is to verify that the device can be

msf2011.086.05

of 68

authenticated across the Ut interface. CDIV is used as an arbitrary service to verify that authentication has been successfully completed.

This test case demonstrates authentication of Ut using Secure HTTP. A future extension to this test case may demonstrate authentication using GAA.

4.1.7.2 Test Setup


• LTE UE1 is pre-provisioned with the XCAP root directory and the user’s directory name.

• Client and MMTel AS are configured to use tls/https with self-signed certificate provisioned on the MMTel AS

• No authentication proxy node exists.



P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS

x x x x x x x x

NOTE: The focus of this test case is Ut interface.

4.1.7.2.2 Procedure • Put LTE UE1 into a state such that no HTTP session exists with the MMTel AS (to force

authentication to occur).

• LTE UE1 performs an xcap-caps, xcap-directory or CDIV service query operation over Ut.

Note: Depending on the LTE UE implementation, it may be necessary to invoke service configuration of a service (e.g. CDIV) to get the LTE UE to authenticate over Ut.

4.1.7.3 Observable Results • When CDIV status is queried the status is displayed to the user.

4.1.7.3.1 Message Flows

Figure 3 – UT Authentication Message Flow


• Verify that https/tls is used between LTE UE1 and MMTel AS.

• Depending on the client implementation one of the following HTTP GET requests will be sent first:

msf2011.086.05

of 68

i. xcap-caps

ii. xcap-directory

iii. cdiv query

• Whichever one is first is the one that will be challenged as per the above message flow.

• Verify that an HTTP 401 Unauthorized response is received from the MMTel AS, and contains a WWW-Authenticate header with the Authentication scheme = Digest. There should be no content in the HTTP 401 response.

• Verify that LTE UE1 resends the same HTTP GET as in the first step, but that it includes an Authorization header containing the challenge response.

• Verify that an HTTP 200 OK is received in response to the HTTP GET with the Authorization header.

• Verify that if LTE UE1 sent an HTTP GET for an “xcap-caps” (i.e. GET /<XCAPRootDirectoryProvisionedOnClient minus Host part>/xcap-caps/global/index HTTP/1.1) that the MMTel AS responds with an HTTP 200 OK response with content similar to the following (additional auids and namespaces may be returned).

<?xml version="1.0" encoding="UTF-8"?>

<xcap-caps xmlns="urn:ietf:params:xml:ns:xcap-caps"

xmlns:xsi="htt//www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:xcap-caps xcap-caps.xsd ">

<auids>

<auid>xcap-caps</auid>

<auid>org.openmobilealliance.xcap-directorty</auid>

<auid>simservs.ngn.etsi.org</auid>

</auids>

<extensions>



</extensions>

<namespaces>

<namespace>urn:ietf:params:xml:ns:xcap-caps</namespace>

<namespace>urn:ietf:params:xml:ns:common-policy</namespace>

<namespace>urn:oma:xml:xdm:common-policy</namespace>

</namespaces>

</xcap-caps>

• Verify that if LTE UE1 sent an “xcap-directory” request (i.e. GET /<XCAPRootDirectoryProvisionedOnClient minus Host part>/services/org.openmobilealliance.xcap-directory/users/<userDirectoryNameProvisionedOnClient>/directory.xml HTTP/1.1), that the MMTel AS responds with an HTTP 200 OK response with content that looks similar to the following:

<?xml version="1.0" encoding="UTF-8"?>

<xcap-directory xmlns="urn:oma:params:xml:xcap-directory">

msf2011.086.05

of 68

<folder auid=" simservs.ngn.etsi.org ">

<entry uri="http://<rootDirectoryProvisionedOnClient>/simservs.ngn.etsi.org/users/<userDirectoryNameProvisionedOnClient>/simservs.xml " etag="1"/>

</folder>

</xcap-directory>

• The contents of the 200 OK response for the CDIV query is outside the scope of this test case as it is tested in a separate Ut configuration test case (“Communication Forwarding Unconditional – Configuration over Ut”).

4.1.7.4 Trace Capture The main focus of this test case is the interaction between the UE and the MMTel AS. It is essential that traces of the messages exchanged on this interface be captured during the testing and validated against the message flow shown above.

4.1.7.5 Known Issues • None.

4.1.8 S1a-8 – Service Configuration over Ut This test case is intentionally left blank, and may be completed at a future date.

4.1.9 S1a-9 - Originating Identification Presentation ( 3GPP TS 24.607)

4.1.9.1 Purpose This test case validates that the terminating user can receive identity information in order to identify the originating user. Based on 3GPP TS 24.607 release 9 version 9.1.0.

4.1.9.2 Test Setup



• LTE UEs both registered in IMS.


• Display name of both Users provisioned in HSS and received by S-CSCF and P-CSCF (P-Associated-URI header) at registration time.

• Terminating user is provisioned with the OIP service (in the HSS or MMTel AS), or the service is generally available.

• OIR service is not being used on LTE UE1

• LTE UE2 does not contain user 1 in their personal address book.


• Network Equipment configured as below:

msf2011.086.05

of 68

LTE UE1

LTE UE2 eNodeB MME

S-GW

P-GW PCRF P-CSCF

I/S-CSCF

MMTel

AS

HSS

x x x x x x x x x x x

NOTE: The focus of this test case is Gm, Mw, and ISC interfaces.



4.1.9.3.1 Message Flows Note: The Message Flow below shows how the SIP INVITE signalling traverses the MMTel AS. SIP responses and subsequent requests are not shown and should be identical to the ones in section 4.1.5.3.1.

Figure xxx – Originating Identification Presentation (OIP) Message Flow


• Verify the originating user’s identity (both name and number) are displayed on LTE UE2 while the call is in the alerting state and for the remainder of the call.

• Verify that when LTE UE2 answers, speech path is established.

• Verify that if LTE UE1 inserted a P-Preferred-Identity in the SIP INVITE, the PPI matches a valid IMPU registered (implicitly or explicitly).

• Verify that the originating P-CSCF removes the P-Preferred-Identity header (if present) from the SIP INVITE and adds a P-Asserted-Identity header with the IMPU from the P-Preferred-Identity header (if present), or the default IMPU (if not present).

Note: default IMPU is the first IMPU in the P-Associated-URI header returned in the 200 OK of the Register.

msf2011.086.05

of 68

• Verify that the originating P-CSCF adds the associated display-name (received during registration) into the P-Asserted-Identity header.

• Verify that if the P-Asserted-Identity header in the SIP INVITE:

i. contains only a sip URI which is an alias for a tel URI, that the originating S-CSCF adds a second P-Asserted-Identity header containing the tel URI and the display name associated with the tel URI (if available).

ii. contains only a tel URI, that the originating S-CSCF adds a second P-Asserted-Identity header containing a SIP URI. The added SIP URI contains in the user part a "+" followed by the international public telecommunication number contained in tel URI, and user's home domain name in the hostport part. The added SIP URI contains the same value in the display name as contained in the tel URI. The S-CSCF shall also add a "user" SIP URI parameter equals "phone" to the SIP URI.

• Verify that the P-Asserted-Identity is carried all the way to LTE UE2 in the SIP INVITE.

• Verify that LTE UE2 displays one or more of the following data contained in the P-Asserted-Identity header:

i. sip URI

ii. tel URI

iii. associated display-name

4.1.9.4 Trace Capture The main focus of this test case is the interaction between the UE – P-CSCF (Gm), the P-CSCF – S-CSCF (Gm), S-CSCF – MMTel AS (ISC). It is essential that traces of the messages exchanged on these interfaces be captured during the testing and validated against the message flow shown above.


4.1.10 S1a-10 - Originating Identification Restriction (3GPP TS 24.607)

4.1.10.1 Purpose This test case validates that the originating user can prevent presentation of its identity information to the terminating user. In particular, this test case is focused on the privacy of the P-Asserted-Identity header. Based on 3GPP TS 24.607 release 9 version 9.1.0.

4.1.10.2 Test Setup






• Terminating user is provisioned with the OIP service (in the HSS or the MMTel AS), or the service is generally available.

msf2011.086.05

of 68

• Originating user is provisioned with the OIR service temporary mode (in the HSS or the MMTel AS) with default value “not restricted”.



LTE UE1

LTE UE2 eNodeB MME

S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS



4.1.10.2.2 Procedure • LTE UE1 places a call to LTE UE2 by dialling the MSISDN based IMPU of LTE UE2.

• Originating user requests OIR for this call.


4.1.10.3.1 Message Flows Note: The Message Flow below shows how the SIP INVITE signalling traverses the MMTel AS. SIP responses and subsequent requests are not shown and should identical to the ones in section 4.1.5.3.1.

Figure 11 – Originating Identification Restriction Message Flow


• Verify that the originating user’s identity is not displayed on LTE UE2.

• Verify that LTE UE2 provides an indication that the originator’s caller id is being restricted.

msf2011.086.05

of 68

• Verify that when LTE UE2 answers, speech path is established and the caller ID display does not change.

• Verify that LTE UE1 anonymizes the From header field in the SIP INVITE as follows:

From: "Anonymous" <sip:[email protected]>;tag= xxxxxxx

• Verify that LTE UE1 includes a Privacy header with value “id” in the SIP INVITE.

• Verify that the terminating S-CSCF or terminating P-CSCF removes the P-Asserted-Identity header.

• Verify that the Privacy header and the anonymized From header are delivered to LTE UE2.



4.1.11 S1a-11 – Service Configuration over Ut of TIP/TIR This test case is intentionally left blank. It may be completed at a future date.

4.1.12 S1a-12 - Terminating Identification Presentation (3GPP TS 24.608)

4.1.12.1 Purpose This test case validates that the originating user can receive identity information in order to identify the terminating user. Based on 3GPP TS 24.608 release 9 version 9.1.0.

4.1.12.2 Test Setup






• Originating user is provisioned with the TIP service (in the HSS or MMTel AS) or the service is generally available.

• TIR service is not being used.

• LTE UE1 does not contain user 2 in their personal address book.



msf2011.086.05

of 68

LTE UE1

LTE UE2 eNodeB MME

S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS





4.1.12.3.1 Message Flows Note: The Message Flow below shows how the SIP INVITE and corresponding 200 OK signalling traverse the MMTel AS. Other SIP responses and subsequent requests are not shown and should be identical to the ones in section4.1.5.3.1.

Figure 12 – Terminating Identification Presentation Message Flow


• Verify that LTE UE2 alerts.

msf2011.086.05

of 68

• When LTE UE2 answers, speech path is established.

• Verify that the terminating user’s identity (both name and number) is displayed on LTE UE1 only after the call is answered.

Note: TS 24.608 states the display is updated once a 2xx response is received.

• Verify that LTE UE1 includes the “from-change” option tag in the “Supported” header of the SIP INVITE.

• Verify that the “from-change” option tag in the Supported header in the SIP INVITE is signalled end to end and delivered to LTE UE2.

• Verify that the terminating S-CSCF adds a P-Called-Party-ID header to the SIP INVITE. The P-Called-Party-ID header should be set to value in the R-URI header of the SIP INVITE.

• Verify that the terminating P-CSCF removes any P-Preferred-Identity header and adds a P-Asserted-Identity header to the 200 OK response; and sets the URI in the PAI to the P-Called-Party-ID header (received in the SIP INVITE) and to the display-name received during registration.

• Verify that if the P-Asserted-Identity header in the 200 OK:

i. contains only a sip URI which is an alias for a tel URI, that the terminating S-CSCF adds a second P-Asserted-Identity header containing the tel URI and the display name associated with the tel URI (if available)

ii. contains only a tel URI, that the terminating S-CSCF adds a second P-Asserted-Identity header containing a SIP URI. The added SIP URI contains in the user part a "+" followed by the international public telecommunication number contained in tel URI, and user's home domain name in the hostport part. The added SIP URI contains the same value in the display name as contained in the tel URI. The S-CSCF shall also add a "user" SIP URI parameter equals "phone" to the SIP URI.

• Verify that the P-Asserted-Identity inserted by the originating P-CSCF is carried all the way to LTE UE1 in the 200 OK response to the INVITE.

• Verify that LTE UE1 displays one or more of the following data contained in the P-Asserted-Identity header of the 200 OK response:

i. sip URI

ii. tel URI

iii. associated display-name



msf2011.086.05

of 68

4.1.13 S1a-13 - Terminating Identification Restriction (3GPP 24.608)

4.1.13.1 Purpose This test case validates that the terminating user can prevent presentation of its identity information to the originating user. In particular, this test case is focused on the privacy of the P-Asserted-Identity header. Based on 3GPP TS 24.608 release 9 version 9.1.0.

4.1.13.2 Test Setup






• Originating user is provisioned with the TIP service (in the HSS or MMTel AS), or the service is generally available.

• Terminating user is provisioned with the TIR service temporary mode with default value “not restricted” (in the HSS or MMTel AS).



LTE UE1

LTE UE2 eNodeB MME

S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS


4.1.13.2.2 Procedure • LTE UE1 places a call to LTE UE2 by dialling the MSISDN based IMPU of LTE UE2.

• Terminating user requests TIR for this call.


4.1.13.3.1 Message Flows Note: The Message Flow below shows how the SIP INVITE and corresponding 200 OK signalling traverse the MMTel AS. Other SIP responses and subsequent requests are not shown and should be identical to the ones in section 4.1.5.3.1 .

msf2011.086.05

of 68

Figure 13 – Terminating Identification Restriction Message Flow



• Verify that the terminating user’s identity is not displayed on LTE UE1.

• Verify that LTE UE1 provides an indication that the caller ID of the terminator has been restricted.

• Verify that when LTE UE2 answers, speech path is established.

• Verify that LTE UE2 includes a Privacy header with value “id” in any provisional and final responses to the SIP INVITE.

• Verify that the terminating P-CSCF removes any P-Preferred-Identity header and adds a P-Asserted-Identity header to the 200 OK response; and sets the URI in the PAI to the P-Called-Party-ID header (received in the SIP INVITE) and to the display-name received during registration.

• Verify that the originating P-CSCF or S-CSCF removes the P-Asserted-Identity header in any provisional and the final 200 responses to the SIP INVITE.

• Verify that the Privacy header is delivered to the originating UE in any provisional and the final 200 response.

msf2011.086.05

of 68



4.1.14 S1a-14 Service Configuration over Ut of CDIV (Communication Forwarding Unconditional)

4.1.14.1 Purpose This test case validates that Communication Forwarding Unconditional can be activated and interrogated over the Ut interface. Based on 3GPP TS 24.604 release 9 version 9.5.0, and TS 24.624 release 9 version 9.2.0.

4.1.14.2 Test Setup


• LTE UE1 is provisioned with Communication Forwarding Unconditional (in HSS or MMTel AS). No other CDIV services are assigned to LTE UE1.

• Communication Forwarding Unconditional is not activated.

• LTE UE1 is pre-provisioned with the XCAP root directory and the user’s directory name.

• Client and MMTel AS are configured to use tls/https with self-signed certificate provisioned on the MMTel AS

• No authentication proxy node.



P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS

x x x x x x x x

NOTE: The focus of this test case is Ut interface.

4.1.14.2.2 Procedure • LTE UE1 queries CDIV status (i.e. interrogation).

• LTE UE1 activates Communication Forwarding Unconditional and sets the forward to number to the MSISDN based IMPU of LTE UE3. No subscription options are set. No media conditions are specified.

• LTE UE1 queries CDIV status (i.e. interrogation).



msf2011.086.05

of 68

Figure 14 – Service Configuration over Ut of CDIV Message Flow


• Verify that when CDIV status is queried before programming Communication Forwarding Unconditional, client displays to user that no CDIV services are activated.

• Verify that when CDIV status is queried after activating Communication Forwarding Unconditional, client displays that Communication Forwarding Unconditional is the only CDIV service activated and displays the correct forward to number (i.e. MSISDN based IMPU of LTE UE3).

• Verify that https/tls is used between LTE UE1 and MMTel AS.

• Verify that LTE UE1 interrogates the status of the CDIV service by sending an HTTP GET request built as follows:

i. GET /<XCAPRootDirectoryProvisionedOnClient minus Host part>/simservs.ngn.etsi.org/users/<userDirectoryNameProvisionedOnClient>/simservs.xml/~~ /simservs/ communication-diversion HTTP/1.1

ii. Host: <host part of XCAPRootDirectoryProvisionedOnClient>

iii. No Content in the GET request

• Note: The client could request the whole simservs document and parse it to find the CDIV service information. In that case the “~~simservs/communication-diversion” portion will not be present in the URI.

• Note: There could be other headers like User-Agent in the HTTP request

• Verify that an HTTP 200 OK response with content-type = “application/simservs+xml” is received in response to both HTTP GET operations.

• If the HTTP 200 OK is received in response to the query that occurs before Communication Forwarding Unconditional is activated (i.e. message 1), then the content should look as follows:

<?xml version="1.0" encoding="UTF-8"?> <simservs xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy"> <communication-diversion active="false"> </communication-diversion> </simservs>

msf2011.086.05

of 68

Note: If the complete simservs document was requested, the elements in blue will be returned and there may be additional service data returned for other services.

• If the 200 OK is received in response to the query that occurs after Communication Forwarding Unconditional is activated (i.e. message 5), then the content should look as follows:

<?xml version="1.0" encoding="UTF-8"?> <simservs xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy"> <communication-diversion active="true"> <cp:ruleset> <cp:rule id=“<RuleIDCreatedByClient>"> <cp:conditions/> <cp:actions> <forward-to> <target> <sip or tel URI of User 3> </target> </forward-to> </cp:actions> </cp:rule> </cp:ruleset> </communication-diversion> </simservs>

Note: If the complete simservs document was requested, the elements in blue will be returned and there may be additional service data returned for other services.

Note: active=”true” does not have to be present, as it is the default setting.

• Verify that the client activates the Communication Forwarding Unconditional service by sending an HTTP PUT request built as follows:

i. PUT /<XCAPRootDirectoryProvisionedOnClient minus Host part>/simservs.ngn.etsi.org/users/<userDirectoryNameProvisionedOnClient>/ simservs.xml/~~ /simservs/ communication-diversion HTTP/1.1

ii. Host: <host part of XCAPRootDirectoryProvisionedOnClient>

iii. Content-Type: application/simservs+xml

iv. And with the following content:

<?xml version="1.0" encoding="UTF-8"?> <simservs xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy"> <communication-diversion active="true"> <cp:ruleset> <cp:rule id=“<RuleIDCreatedByClient>"> <cp:conditions/> <cp:actions> <forward-to> <target> <sip or tel URI of User 3> </target> </forward-to> </cp:actions> </cp:rule> </cp:ruleset>

msf2011.086.05

of 68

</communication-diversion> </simservs>

Note: The client could send the whole simservs document in which case the “~~simservs/communication-diversion” portion will not be present in the URI.

Note: If the complete simservs document was sent from the client, the elements in blue will be included and there may be additional service data sent for other services.

Note: There could be other headers like User-Agent in the PUT

Note: active=”true” does not have to be present, as it is the default setting.

• If UE does not include an Authorization header with the previous challenge response, then verify that the HTTP GET/PUT is challenged by the MMTel AS. Use the Pass/Fail Criteria from the “Authentication for Ut Configuration” test case.

• If LTE UE1does include an Authorization header, and the MMTel AS still challenges the request (i.e. HTTP 401 response); then use the Pass/Fail Criteria from the “Authentication for Ut Configuration” test case.

• If LTE UE1 sends an HTTP GET for an “xcap-caps” or “org.openmobilealliance.xcap-directorty” request to the MMTel AS, use the Pass/Fail Criteria from the “Authentication for Ut Configuration” test case.

4.1.14.4 Trace Capture The main focus of this test case is the interaction between the UE – MMTel AS (Ut). It is essential that traces of the messages exchanged on this interface be captured during the testing and validated against the message flow shown above.


4.1.15 S1a-15 - Communication Forwarding Unconditional (3GPP TS 24.604)

4.1.15.1 Purpose This test case validates that an incoming call can be diverted using Communication Forwarding Unconditional. Based on 3GPP TS 24.604 release 9 version 9.5.0.

4.1.15.2 Test Setup




• LTE UE1, LTE UE2 and LTE UE3 all have registered originating and registered terminating iFCs for SIP INVITE requests to the MMTel AS provisioned in their subscriber profile on the HSS.


• LTE UE2/user 2 is provisioned with the Communication Diversion Unconditional service (in the HSS or the MMTel AS).

• LTE UE/user 2 has previously activated Communication Forwarding Unconditional and the target is set to user 3 (i.e. MSISDN based IMPU of LTE UE3).

msf2011.086.05

of 68

• Subscription options for CDIV Communication Forwarding Unconditional service are set to default values:

o Served user receives indication that a communication has been forwarded = No.

o Originating user receives notification that his communication has been diverted = Yes.

o Served user allows the presentation of diverted to URI to originating user in diversion notification: Yes.

o Served user receives reminder indication on outgoing communication that CDIV is currently activated = No.

o Served user allows the presentation of his/her URI to diverted-to user = Yes.

o Served user allows the presentation of his/her URI to originating user in diversion notification = Yes.

• MMTel AS is not configured to play announcement towards the calling user in order to inform the originator about the diversion.


LTE UE1

LTE UE 2

LTE UE3 eNodeB MME S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS


4.1.15.2.2 Procedure • LTE UE1 places a call to LTE UE2 by dialling the MSISDN IMPU of LTE UE2.

• LTE UE3 answers the call.


4.1.15.3.1 Message Flows Note: The SIP responses/subsequent requests are not shown, they should be identical to the ones in section 4.1.5.3.1 except that they traverse the originating MMTel AS, forwarding MMTel AS and terminating MMTel AS.

msf2011.086.05

of 68

Figure 15 – Communication Diversion Unconditional Message Flow


• Verify that LTE UE2 does not alert.


• Verify that when LTE UE3 answers the call, speech path is established between LTE UE1 and LTE UE3.

• Verify that if LTE UE1 and/or LTE UE 3 optionally display call redirection information, that the information is correct and built from the contents of the History-Info header.

• Verify that the SIP INVITE that is sent to LTE UE2’s MMTel AS (message 5) does not contain a History-Info header.

msf2011.086.05

of 68

• Verify that LTE UE2’s MMTel AS sends an outgoing SIP INVITE that is built as follows:

i. The R-URI is set to the sip or tel URI corresponding to the IMPU for user 3

ii. A History-Info header with the following 2 hist-info entries:

1. The first hist-info entry includes the hi-targeted-to-uri of the served user (i.e. IMPU of user 2), and the index is set to 1 (note RFC 4244 allows this to be another number as long as there are no dots).

2. The second hist-info entry includes the new Request-URI (i.e. IMPU of user 3) as the hi-targeted-to-uri and a cause-param parameter in non-escaped format. The cause-param is embedded in the hi-targeted-to-uri. The cause-param is set to cause value “302”.

Example History-Info header:

History-Info: <URI of user 2>;index=1,<URI of user 3;cause=302>;index=1.1

iii. Retains the same To header URI (i.e. user 2) as in the received INVITE.

iv. Retains the same P-Asserted-Identity (i.e. user 1) as in the received INVITE.

• Verify that LTE UE2’s MMTel AS responds with a 181 (Call Is Being Forwarded) response (message 6a) towards the originating user. The following header fields should be included:

i. A P-Asserted-Identity with the URI of the diverting user (i.e. user 2 IMPU)


1. The first hist-info entry includes the hi-targeted-to-uri of the served user (i.e. user 2 IMPU). The Index is set to index=1.

2. The second hist-info entry includes the new Request-URI (i.e. IMPU of user 3) as hi-targeted-to-uri and a cause-param parameter in non-escaped format. The cause-param is embedded in the hi-targeted-to-uri. The cause-param is set to cause value “302”.



• Verify that the 181 response is signalled end to end and that LTE UE1 receives the 181 response.

• Verify that if LTE UE1 displays call redirection information, the data corresponds to the contents of the History-Info header of the 181 response.

• Verify that the MMTel AS for LTE UE3 inserts the History-Info header received in the INVITE in the 180 Ringing and 200 OK responses from LTE UE3 (not shown in message flow).



msf2011.086.05

of 68

4.1.16 S1a-16 – Communication Forwarding on not Logged in (3GPP TS 24.604)

4.1.16.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Communication Forwarding on not Logged in, between two LTE UEs in the same PLMN.

4.1.16.2 Test Setup


• EPS Subscriber information for the UE registered to the network is configured in the HSS, MMTel AS and the PCRF.

• UE-A and UE-C are both registered in IMS.

• UE-A, UE-B and UE-C all have registered originating and registered terminating iFCs for SIP INVITE requests to the MMTel AS provisioned in their subscriber profile on the HSS.


• UE-B is provisioned with the Communication Diversion Not Logged In service (in the HSS or the MMTel AS).

• UE-B/user B has previously activated Communication Forwarding Not Logged In and the target is set to user C (i.e. MSISDN based IMPU of UE-C).

• Subscription options for CDIV Communication Forwarding Not Logged In service are set to default values:







• UE-B is registered in IMS in the same PLMN as UE-A and UE-C..


LTE UE-A

LTE UE-B

LTE UE-C eNodeB MME S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS

x x x x x x x x x x x x


•

4.1.16.2.2 Procedure • UE-A places a call to UE-B by dialling the MSISDN IMPU of UE-B.

• UE-C answers the call.

msf2011.086.05

of 68


4.1.16.3.1 Message Flows The voice call flow with CFNL service is shown below.


Note: in this figure, some network elements irrespective to this supplementary service are omitted.

Note: In some cases the invite and responses will traverse AS-A or AS-C. This is not shown on the diagram.

UE-A UE-BCSCF-BAS-BCSCF-A

1. INVITESession: A1 offera=sendrecv

4. INVITE 5. INVITESession: A1 offer

2. INVITE3. INVITE

UE-C

UE-B isn’t Logged-in,trigger CFNL service

7. 181/PRACK/200 OK8. 181/PRACK/200 OK

6. 181/PRACK/200 OK

19. 200 OK(INVITE)Session : C1 answera=sendrecv

21. 200 OK(INVITE)

20. 200 OK(INVITE)

22. 200 OK(INVITE)23. 200 OK(INVITE)Session : C1 answer

25. ACK

26. ACK

27. ACK28. ACK

24. ACK

9. 180

11. 180

10. 180

12. 18013. 180

15. PRACK/200 OK

16. PRACK/200 OK

17. PRACK/200 OK18. PRACK/200 OK

14. PRACK/200 OK

Figure 16 – Communication Forwarding on Not Logged in Message Flow


• Verify that UE-B does not alert.

• Verify that UE-C alerts.

• Verify that when UE-C answers the call, speech path is established between UE-A and UE-C.

• Verify that if UE-A and/or UE-C optionally display call redirection information, that the information is correct and built from the contents of the History-Info header.

• Verify that the SIP INVITE that is sent to UE-B’s MMTel AS (message 3) does not contain a History-Info header.

msf2011.086.05

of 68

• Verify that UE-B’s MMTel AS sends an outgoing SIP INVITE that is built as follows:

i. The R-URI is set to the sip or tel URI corresponding to the IMPU for user C


1. The first hist-info entry includes the hi-targeted-to-uri of the served user (i.e. IMPU of user B), and the index is set to 1 (note RFC 4244 allows this to be another number as long as there are no dots).

2. The second hist-info entry includes the new Request-URI (i.e. IMPU of user C) as the hi-targeted-to-uri and a cause-param parameter in non-escaped format. The cause-param is embedded in the hi-targeted-to-uri. The cause-param is set to cause value “404”.



iii. Retains the same To header URI (i.e. user B) as in the received INVITE.

iv. Retains the same P-Asserted-Identity (i.e. user A) as in the received INVITE.

• Verify that UE-B’s MMTel AS responds with a 181 (Call Is Being Forwarded) response (message 6) towards the originating user. The following header fields should be included:

i. A P-Asserted-Identity with the URI of the diverting user (i.e. user B IMPU)


1. The first hist-info entry includes the hi-targeted-to-uri of the served user (i.e. user B IMPU). The Index is set to index=1.




• Verify that the 181 response is signalled end to end and that UE-A receives the 181 response.

• Verify that if UE-A displays call redirection information, the data corresponds to the contents of the History-Info header of the 181 response.

• Verify that the MMTel AS for UE-C inserts the History-Info header received in the INVITE in the 180 Ringing and 200 OK responses from UE-C.



msf2011.086.05

of 68

4.1.17 S1a-17 - Communication Forwarding on Busy (3GPP TS 24.604)

4.1.17.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Communication Forwarding on Busy, between two LTE UEs in the same PLMN.

4.1.17.2 Test Setup


• EPS Subscriber information for the UEs registered to the network is configured in the HSS, MMTel AS and the PCRF.

• UE-A, UE-B and UE-C all registered in IMS.



• UE-B is provisioned with the Communication Diversion Busy service (in the HSS or the MMTel AS).

• UE-B/user B has previously activated Communication Forwarding Busy and the target is set to user C (i.e. MSISDN based IMPU of UE-C).

• UE-B is involved in a call.

• Subscription options for CDIV Communication Forwarding Busy service are set to default values:








• UE-B does not have Communication Waiting enabled.


LTE UE-A

LTE UE-B


P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS




msf2011.086.05

of 68



4.1.17.3.1 Message Flows The voice call flow with CFB service is shown below.




4'. INVITE 5'. INVITESession：A1 Offer

6'. 4867'. 4868'. ACK

9'. ACK

Trigger CFB service




2. INVITE3. INVITE

UE-C

7. 181/PRACK/200 OK8. 181/PRACK/200 OK

6. 181/PRACK/200 OK


21a. 200 OK(INVITE)

20. 200 OK(INVITE)


25. ACK

26. ACK

27. ACK28. ACK

24. ACK

9. 180

11. 180

10. 180

12. 18013. 180

15. PRACK/200 OK

16. PRACK/200 OK


14. PRACK/200 OK

Figure 17 – Communication Forwarding on Busy Message Flow


msf2011.086.05

of 68

• Verify that the call is not presented on UE-B.

• Verity that UE-B responds with a 486 Busy Here when presented with the Invite (message 5).



• Verify that if UE-A and/or UE-C optionally display call redirection information, that the information is correct and built from the contents of the History-Info header.

• Verify that the SIP INVITE that is sent to UE-B’s MMTel AS (message 3) does not contain a History-Info header.



















msf2011.086.05

of 68




4.1.18 S1a-18 - Communication Forwarding on not Reachable (3GPP TS 24.604)

4.1.18.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Communication Forwarding on not Reachable, between two LTE UEs in the same PLMN.

4.1.18.2 Test Setup


• EPS Subscriber information for the UEs registered to the network is configured in the HSS, MMTel AS and the PCRF.




• UE-B is provisioned with the Communication Diversion not Reachable service (in the HSS or the MMTel AS).

• UE-B/user B has previously activated Communication Forwarding not Reachable and the target is set to user C (i.e. MSISDN based IMPU of UE-C).

• UE-B is not reachable – can remove battery to create this condition, or turn off device, as long as UE-B remains registered in IMS.








msf2011.086.05

of 68



LTE UE-A

LTE UE-B


P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS





4.1.18.3.1 Message Flows The voice call flow with CFNRc service is shown below.




msf2011.086.05

of 68

4'. INVITE

7'. ACK

Trigger CFNRc service




2. INVITE3. INVITE

UE-C

7. 181/PRACK/200 OK8. 181/PRACK/200 OK

6. 181/PRACK/200 OK


21a. 200 OK(INVITE)

20. 200 OK(INVITE)


25. ACK

26. ACK

27. ACK28. ACK

24. ACK

9. 180

11. 180

10. 180

12. 18013. 180

15. PRACK/200 OK

16. PRACK/200 OK


14. PRACK/200 OK

Or 6b’. 408/500/503

8'. 200OK

5'. INVITE6a’. Waiting timer is trigger

Figure 18 – Communication Forwarding on not Reachable Message Flow


• Verify that the P-CSCF attempts to deliver the call to UE-B

• Verity that the MMTel-AS for UE-B does not forward the call until one of the following responses is received: 408. 503 or 500.


msf2011.086.05

of 68


• Verify that if UE-A and/or UE-C optionally display call redirection information, that the information is correct and built from the contents of the History-Info header.Verify that the SIP INVITE that is sent to UE-B’s MMTel AS (message 3) does not contain a History-Info header.




















msf2011.086.05

of 68



4.1.19 S1a-19 - Communication Forwarding on No Reply

4.1.19.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Communication Forwarding on No Reply, between two LTE UEs in the same PLMN.

4.1.19.2 Test Setup






• UE-B is provisioned with the Communication Diversion no Reply service (in the HSS or the MMTel AS).

• UE-B/user B has previously activated Communication Forwarding no Reply and the target is set to user C (i.e. MSISDN based IMPU of UE-C).









• MMTel AS “Communication forwarding on no reply timer” is set to 30 seconds.


LTE UE-A

LTE UE-B


P-GW PCRF

P-CSCF

I/S-CSCF MMTel

msf2011.086.05

of 68

AS HSS




• UE-B does not answer the call.



4.1.19.3.1 Message Flows The voice call flow with CFNR service is shown below.




msf2011.086.05

of 68


10. INVITESession: A1 offer

UE-C

12. 181/PRACK/200 OK13. 181/PRACK/200 OK

11. 181/PRACK/200 OK

9. INVITESession: A1 offer

UE-B is ringing, and UE-A is listening the back ring.

The timer(From Invite to waiting for 200(invite)) is time out，trigger CFNR service.

1. CANCEL 2. CANCEL3. 200 OK4. 200 OK

6. 487 5. 487

8. ACK7.ACK


26. 200 OK(INVITE)

25. 200 OK(INVITE)


30. ACK

31. ACK

32. ACK33. ACK

29. ACK

16. 180

15. 180

17. 18018. 180

20. PRACK/200 OK

21. PRACK/200 OK


19. PRACK/200 OK

14. 180

Figure 19 – Communication Forwarding on No Reply Message Flow


• Verify that the P-CSCF attempts to deliver the call to UE-B

• Verity that the MMTel-AS for UE-B does not forward the call until 30 seconds after the first 180 Ringing is received by the MMTel-AS from UE-B.

• Verify that UE-A can hear audible ringback when call is presented to both UE-B and UE-C.



• Verify that if UE-A and/or UE-C optionally display call redirection information, that the information is correct and built from the contents of the History-Info

msf2011.086.05

of 68

header.Verify that the SIP INVITE that is sent to UE-B’s MMTel AS (message not shown) does not contain a History-Info header.






















msf2011.086.05

of 68

4.1.20 S1a-20 – Communication Barring of All Incoming Calls (3GPP TS 24.611)

4.1.20.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Communication Barring of All Incoming Calls, between two LTE UEs in the same PLMN.

4.1.20.2 Test Setup



• UE-A, and UE-B are both registered in IMS.

• UE-A and UE-B have registered originating and registered terminating iFCs for SIP INVITE requests to the MMTel AS provisioned in their subscriber profile on the HSS.


• UE-B is provisioned with the Communication Barring of All Incoming calls service (in the HSS or the MMTel AS).MMTel AS is NOT configured to play an announcement for ICB service.


LTE UE-A

LTE UE-B eNodeB MME S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS




4.1.20.3.1 Message Flows The voice call flow with ICB service is shown below.


NOTE: on this figure, some network elements irrespective to this supplementary service are omitted.

Note: Playing of announcements is optional, so steps 4 to 9 in the following diagram are not required. They are included here to cover the cases where they are provided.

Note: the following diagram should show a 603 response (instead of 403) in step 11 below.

msf2011.086.05

of 68

AS-BCSCF-A/BUE-A

1. INVITE SDP A

2. INVITE SDP A

4. 183 MRF SDP

5. 183 MRF SDP

6. PRACK/7. 200 OK

8. PRACK/9. 200 OK

3. AS-B Invoke ICB Service,Reject the call,Play notify tone

11. 403 forbidden

12. 403 forbidden

13. ACK

14. ACK

9. Play notify tone for period of time,then stop

the tone

UE-B

Figure 20 – Barring of All Incoming Calls Message Flow


• Verify that the call is not delivered to UE-B

• Verify that the terminating MMTel-AS (i.e. UE-B MMTel AS) rejects call with a 603 decline.

• Verify that UE-A displays an appropriate message/alert when the call is rejected.


msf2011.086.05

of 68


4.1.21 S1a-21 – Communication Barring of All Outgoing Calls (3GPP TS 24.611)

4.1.21.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Barring of All Outgoing Calls, between two LTE UEs in the same PLMN.

4.1.21.2 Test Setup






• UE-A is provisioned with the Communication Barring of All Outgoing calls service (in the HSS or the MMTel AS).

• MMTel AS is NOT configured to play an announcement for OCB service.


LTE UE-A


P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS


4.1.21.2.2 Procedure • UE-A places a call.to any valid registered number.


4.1.21.3.1 Message Flows The voice call flow with OCB service is shown below.



Note: Playing of announcements is optional, so steps 4 to 10 in the following diagram are not required. They are included here to cover the cases where they are provided.

Note: the following diagram should show a 603 response (instead of 403) in step 11 below.

msf2011.086.05

of 68

1. INVITE SDP A

2. INVITE SDP A

4. 183 MRF SDP

5. 183 MRF SDP

6. PRACK/7. 200 OK

8. PRACK/9. 200 OK

3. AS-A Invoke OCB Service by K value,Reject the call,Play notify tone

11. 403 forbidden

12. 403 forbidden

13. ACK

14. ACK

10. Play notify tone for period of time,then stop the tone

AS-ACSCF-AUE-A PLMN-B

Figure 21 – Barring of All Outgoing Calls Message Flow


• Verify that the call is not delivered to UE-B

• Verify that the originating MMTel-AS (i.e. UE-A MMTel AS) rejects call with a 603 decline.

• Verify that UE-A displays an appropriate visual/audible alert when the call is rejected.


msf2011.086.05

of 68


4.1.22 S1a-22 – Communication Barring of Outgoing International Calls (3GPP TS 24.611)

4.1.22.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Communicaiton Barring of Outgoing International Calls, between two LTE UEs in the same PLMN.In this case, the target UE is in the same PLMN as the originating UE, but is registered in its home PLMN, which is in a different country.

4.1.22.2 Test Setup

4.1.22.2.1 Test Pre-conditions • Network configuration is as Section 4.1.





• UE-A is provisioned with the Communication Barring of Outgoing International calls service (in the HSS or the MMTel AS).


• The MSISDN based IMPU of UE-A UE-B are such that they have different country codes. This could occur if UE-B was roaming, and registered in its home PLMN

• MMTelNetwork Equipment configured as below:-

LTE UE-A


P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS




4.1.22.3.1 Message Flows Refer to Message Flow in section 4.1.21.3.1

4.1.22.3.2 Pass/Fail criteria Refer to Pass/Fail criteria in section 4.1.21.3.2

msf2011.086.05

of 68



4.1.23 S1a-23 - Barring of Outgoing International Calls – ex Home Country (3GPP TS 24.611)

4.1.23.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Barring of Outgoing International Calls-ex Home Service, between two LTE UEs in different PLMNs.

4.1.23.2 Test Setup

4.1.23.2.1 Test Pre-conditions • Network configuration is as Section 4.1.

• EPS Subscriber information for the UE registered to the network is configured in the HSS, MMTel AS and the PCRF.UE-A, and UE-B are both registered in IMS.



• UE-A is provisioned with the Communication Barring of Outgoing International calls-ex Home Service (in the HSS or the MMTel AS).


• The MSISDN based IMPU of UE-A UE-B are such that they have different country codes.

• UE-B is roaming in the home country of UE-A

• MMTelNetwork Equipment configured as below:-

LTE UE-A


P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS




4.1.23.3.1 Message Flows Refer to Message Flow in section 4.1.21.3.1.

4.1.23.3.2 Pass/Fail criteria Refer to Pass/Fail criteria in section 4.1.21.3.2

msf2011.086.05

of 68



4.1.24 S1a-24 - Barring of Incoming Calls – When Roaming (3GPP TS 24.611)

4.1.24.1 Purpose This test case validates that a terminating MMTel AS can reject incoming calls to a user who is roaming. Based on 3GPP TS 24.611 release 9 version 9.3.0.

4.1.24.2 Test Setup


• LTE UE1 is registered in IMS.


• LTE UE1 and LTE UE2 both have iFCs for SIP REGISTER requests (initial, re-registration and deregistration) to the MMTel AS provisioned in their subscriber profile on the HSS.

• LTE UE2 is provisioned with the “Barring of Incoming Calls – When Roaming” service (in the HSS or MMTel AS).

• LTE UE2/user 2’s home network ID is provisioned in the HSS/MMTel AS.


• MMTel AS not provisioned to play a call barring announcement to the calling user.


LTE UE1

LTE UE2 eNodeB MME

S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS



4.1.24.2.2 Procedure • LTE UE2 performs an IMS registration in the home network

• LTE UE1 calls LTE UE2 by dialling the MSISDN IMPU of LTE UE2.


4.1.24.3.1 Message Flows The message flow is identical to the Message Flow shown in section 4.1.5.3.1.

msf2011.086.05

of 68

4.1.24.3.2 Pass/Fail criteria • Verify the call succeeds.

• Use the Pass/Fail Criteria from section 4.1.5.3.2.



4.1.25 S1a-25 - Communication Hold (3GPP TS 24.610)

4.1.25.1 Purpose This test case validates that a call can be placed on HOLD and RESUMED. Based on 3GPP TS 24.610 release 9 version 9.1.0.

4.1.25.2 Test Setup



• LTE UE1, LTE UE2 both have registered originating and registered terminating iFCs for SIP INVITE requests to the MMTel AS provisioned in their subscriber profile on the HSS.


• LTE UE1 is provisioned with the Communication Hold service (in the HSS or the MMTel AS) or the service is generally available.

• MMTel AS is not provisioned with the network option to lower the bandwidth.

• MMTel AS is not provisioned with the to play an announcement to the held user.

• A call has been established between LTE UE1 and LTE UE2 and speech path exists.


LTE UE1

LTE UE2 eNodeB MME

S-GW

P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS



4.1.25.2.2 Procedure • LTE UE1 places LTE UE2 on hold.

• LTE UE1 retrieves/resumes call to LTE UE2.



msf2011.086.05

of 68

Note: Following message flow assumes the MMTel AS added itself to the record-route when the call was established. Same call flow applies for Communication Hold and for Communication Resume (just the contents of the SDP are different).

Figure 22 – Communication Hold Message Flow


• Verify that there is no speech path when call is on hold.

• Verify that speech path exists when LTE UE1 retrieves the call.

msf2011.086.05

of 68

• Verify if LTE UE 1 and LTE UE 2 optionally indicate to the user that the call is in the Hold state.

• Verify that LTE UE1 does the following when placing the call on HOLD:

i. Sends a SIP Re-INVITE or SIP UPDATE message to LTE UE2.

ii. The SIP Re-INVITE or SIP UPDATE contains an SDP offer with “sendonly” SDP attribute for the media path.

iii. Sends an ACK to any 200 OK response to a SIP Re-INVITE. No ACK if UPDATE used.

• Verify that LTE UE1 does the following when retrieving the call from HOLD:

i. Sends a SIP Re-INVITE or SIP UPDATE message to LTE UE2.

ii. The SIP Re-INVITE or SIP UPDATE contains an SDP offer with “sendrecv” or no SDP attribute for the media path.

iii. Sends an ACK to any 200 OK response to a SIP Re-INVITE. No ACK if UPDATE used.

• Verify that LTE UE2 responds to the HOLD SIP Re-INVITE or SIP UPDATE with a 200 OK response. For SIP Re-INVITE an ACK should also be sent.



4.1.26 S1a-26 - Message Waiting Indication (3GPP TS 24.606)

4.1.26.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Message Waiting Indication, the MWI AS is in HOME network of UE.

4.1.26.2 Test Setup


• EPS Subscriber information for the UE registered to the network is configured in the HSS, MMTel AS and the PCRF.UE-A is not registered in IMS.

• UE-A has registered originating and registered terminating iFCs for SIP SUBSCRIBE (message-summary package) requests to the MWI AS provisioned in their subscriber profile on the HSS.

• MWI AS is in the trust domain.

• UE-A is provisioned with the MWI service (in the HSS or the MMTel AS).

• There are 0 messages waiting for UE-A.


LTE UE eNodeB MME S-GW P-GW PCRF P-CSCF

I/S-CSCF

MMTel AS

HSS

x x x x x x x x x x

msf2011.086.05

of 68


4.1.26.2.2 Procedure • UE-A is forced to subscribe for the message-summary event package (e.g. turn UE on).

• A message is left for UE-A


4.1.26.3.1 Message Flows The voice call flow with WMI service is shown below.



P-GW-A(UE-A) CSCF-A MWI AS-A

1.SUBSCRIBE

2.Elaluation of iFC

3.SUBSCRIBE

4. 200OK(SUB)

5. 200OK(SUB)

6. NOTIFY

7. NOTIFY

8.200OK(NOTIFY)

9.200OK(NOTIFY)

10. notifications on message-summary event package

11. NOTIFY12. NOTIFY

13.200OK(NOTIFY)

14.200OK(NOTIFY)

Figure 23 – Message Waiting Indication Message Flow


• Verify that UE-A subscribes for the message-summary package.

• Verify that UE-A displays that there are 0 messages waiting when subscription for the message-summary package completes and first Notify is received.

• Verify that UE-A displays that there is 1 message waiting after the message is put into UE-A’s mailbox.

msf2011.086.05

of 68

4.1.26.4 Trace Capture The main focus of this test case is the interaction between the UE – P-CSCF (Gm), the P-CSCF – S-CSCF (Gm), S-CSCF – MWI AS (ISC). It is essential that traces of the messages exchanged on these interfaces be captured during the testing and validated against the message flow shown above.


4.1.27 S1a-27- UE-based Communication Waiting ( 3GPP TS 24.615)

4.1.27.1 Purpose This test case validates that a second incoming call can be answered, and the existing call is placed on HOLD, and that when the second call is released, the first call can be retrieved. Based on 3GPP TS 24.615 release 9 version 9.3.0.

4.1.27.2 Test Setup



• LTE UE1, LTE UE2, LTE UE3 all have registered originating and registered terminating iFCs for SIP INVITE requests to the MMTel AS provisioned in their subscriber profile on the HSS.


• LTE UE2 is provisioned with Communication Waiting service (in the HSS or MMTel AS) or the service is generally available.

• MMTel AS not provisioned to play an announcement to the calling user.

• MMTel AS not provisioned with the AS-CW Timer.

• LTE UE1 and LTE UE2 are in an established call.


LTE UE1

LTE UE2

LTE UE3

eNodeB MME S-GW P-GW PCRF

P-CSCF

I/S-CSCF

MMTel

AS

HSS



4.1.27.2.2 Procedure • LTE UE3 places a call to LTE UE2 by dialling the MSISDN IMPU of LTE UE2.

• LTE UE2 answers incoming call from LTE UE3.

• LTE UE3 releases call to LTE UE2.

• LTE UE2 retrieves call to LTE UE1.

4.1.27.3 Observable Results • While waiting for LTE UE2 to answer the call, LTE UE3 may optionally indicate to the user

that the call is being treated as a waiting communication.

• LTE UE2 provides CW indication to the terminating user.

msf2011.086.05

of 68

• LTE UE3 may also provide some CW indication to the originating user.

• When LTE UE2 answers call from LTE UE3:

i. CW indication to the user is stopped on LTE UE3 and LTE UE2.

ii. Speech path is not present between LTE UE1 and LTE UE2.

iii. Speech path is established between LTE UE3 and LTE UE2.

• When LTE UE3 releases call to LTE UE2:

i. Speech path is resumed between LTE UE1 and LTE UE2. This may be done automatically by the LTE UE2, or require subscriber interaction.

4.1.27.3.1 Message Flows The voice call flow with OIR service is shown below.


NOTE: All the messages between the two PLMNs(IMS-CN A & B), including signalling and media, go through the IBCF/TrGW located on the border of each domain.

NOTE: on this figure, some network elements not related to this supplementary service are omitted.

msf2011.086.05

of 68

Figure 24 – Communication Waiting Message Flow


• Verify that LTE UE2 responds to the SIP INVITE from LTE UE3 with a 180 (Ringing) response with the Alert-Info header field set to "<urn:alert:service:call-waiting>" the Alert-Info is signalled end to end all the way to LTE UE3.

• Verify the Pass/Fail Criteria from Communication Hold Testcase for when LTE UE1 is placed on hold and later retrieved/resumed.

• Verify the Pass/Fail Criteria from the “IMS Voice Session Establishment” test case for the call setup between LTE UE3 and LTE UE2.

• Verify the Pass/Fail Criteria from the “IMS Voice Session Termination” test case for the releasing of the call from LTE UE3 to LTE UE2.


msf2011.086.05

of 68


4.1.28 S1a-28 Ad-Hoc Multi Party Conference (3GPP TS 24.605)

4.1.28.1 Purpose This test case demonstrates the ability to perform interworking between all nodes by performing a type of IMS supplementary service: Ad-Hoc Multi Party Conference, between two LTE UEs in the same PLMN.

4.1.28.2 Test Setup



• Three LTE UEs are registered in different PLMNs, such as UE-A is registered in PLMS-A and UE-B/C is registered in PLMN-B.

• UE-B/C are normal subscriber, UE-A has applied for the CONF service


LTE UE eNodeB MME S-GW P-GW PCRF P-CSCF

I/S-CSCF

MMTel AS

HSS

x x x x x x x x x x

NOTE: The focus of this test case is SGi, ISC, Mw, Mx, Ici and Izi interfaces.


• UE-A places a call to UE-C by dialling the MSISDN IMPU of UE-C. (Note, client may support automatic hold of call to UE-B, or require user to put call on hold explicitly).

• UE-A creates an ad-hoc multi party conference with UE-B and UE-C


4.1.28.3.1 Message Flows The voice call flow with CONF service is shown below.



NOTE: The network signalling about UE-A is omitted in the figure. The UE-B is already involved in one or more communications.

msf2011.086.05

of 68

(Initially A-‐B call (B held) and A-‐C call (speech), A initiates CONF service)

202 Accepted (5)

Invite (Replaces, SDP-‐MRF) (7)Notify (100 Trying) (6)

200 OK (Notify) (7)

100 Trying

Ack Notify (200 OK) (10)

200 OK (Notify) (11)

Bye (12)

200 OK (Bye) (13)

Refer (Refer-‐To B/C, Replaces) (4)

Invite (SDP-‐A) (1)

Ack (3)200 OK (Invite) (SDP-‐MRF) (2)

200 OK (Invite) (SDP-‐B/C) (9)

100 Trying

Figure 25 – Ad-Hoc Multi Party Conference Message Flow


• Verify that the key headers of each SIP message are correct.

• Procedure 1: UE_A sends an INVITE request which applies for multi-way call resource to AS_A via S-CSCF_A; then, AS_A will reserve multi-way call resource from (embedded) MRF.

• Procedure 2: After reserving the MRF resource successfully, AS_A sends a 200OK response to UE_A with conference media and multi-way-call number via S-CSCF_A.

• Procedure 3: After receiving the response, UE_A sends an ACK message to AS-A via S-CSCF_A.

• Procedure 4: UE_A sends a in dialog REFER message which contains refer to and replace field parameter to indicate that UE_B is to be invited into the three-way calling to AS_A.

• Procedure 5: After sending a 202 response for REFER message, then AS_A requests further conference resource from MRF.

• Procedure 6: AS_A obtains further conference resource successfully, then sends a NOTIFY(100 trying) to UE_A ;

• Procedure 7: UE_A sends a 200 response for NOTIFY(100 trying) request to AS_A;

msf2011.086.05

of 68

• Procedure 8 AS_A sends an INVITE request to UE_B with conference resource media via S-CSCF_B. This INVITE contains the SIP Replaces header to identify the existing (2 party) session that is being moved into conference.

• Procedure 9: UE_B sends a 200OK response with SDP-B for the INVITE request to AS_A；

• Procedure 10: AS_A passes B’s SDP to the conference resource and sends a NOTIFY (200) message to UE_A ;UE_A send a 200OK message to AS_A;AS_A also sends an ACK message to UE_B which indicates that UE_B has attended the conference successfully

• Procedure 11: UA_A sends a 200 OK to the NOTIFY.

• Procedure 12: On receipt of the ACK indicating that B has been accepted into conference, UE_B sends a BYE to terminate the original 2-party session with UE_A.

• Procedure 13 :- UE_A sends a 200 OK to the BYE.

• Steps 4-13 are then repeated for UE_C, leaving parties A,B & C in a 3-way conference.

• .



msf2011.086.05

of 68

Annex Abbreviations AF Application Function ANR Automatic Neighbour Relation APN Access Point Name ARP Allocation and Retention Priority AMBR Aggregate Maximum Bit Rate DL TFT DownLink Traffic Flow Template EBI EPS Bearer ID ECGI E-UTRAN Cell Global Identifier ECM EPS Connection Management EMM EPS Mobility Management eNodeB Evolved Node B ESM EPS Session Management EPC Evolved Packet Core EPS Evolved Packet System E-RAB E-UTRAN Radio Access Bearer E-UTRAN Evolved Universal Terrestrial Radio Access Network F-TEID Fully Qualified Tunnel Endpoint Identifier GBR Guaranteed Bit Rate GPRS General Packet Radio Service GTP GPRS Tunnelling Protocol GUMMEI Globally Unique MME Identifier GUTI Globally Unique Temporary Identity GW Gateway IMSI International Mobile Subscriber Identity ISR Idle mode Signalling Reduction IMPU IP Multimedia Public Identity LBI Linked EPS Bearer Id MBR Maximum Bit Rate MME Mobility Management Entity MMEC MME Code M-TMSI M-Temporary Mobile Subscriber Identity NAS Non Access Stratum PAA PDN Address Allocation PCO Protocol Configuration Options P-GW PDN Gateway PMIP Proxy Mobile IP PTI Procedure Transaction Id QCI QoS Class Identifier QoS Quality of Service RAT Radio Access Type RFSP RAT/Frequency Selection Priority S-GW Serving Gateway S-TMSI S-Temporary Mobile Subscriber Identity SDF Service Data Flow TAC Tracking Area Code TAD Traffic Aggregate Description TAI Tracking Area Identity TAU Tracking Area Update TI Transaction Identifier TIN Temporary Identity used in Next update UL TFT Uplink Traffic Flow Template ULI User Location Information

Multiservice Switching Forum Contribution

Documents

Transcript of Multiservice Switching Forum Contribution