Multiservice Switching Forum Contribution

Transcription

1 Multiservice Switching Forum Contribution Contribution Number: msf Last Saved: 03/26/ :03 A3/P3 Working Group: Interoperability and Test Title: Test Plan for LTE/EPC Interoperability Event Scenario 4 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. This contribution specifically covers the intra-rat handovers which form part of Scenario 4 (as defined in the Physical Scenarios Document msf ). Inter-RAT handovers may be added in a future version of this document. 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.

2 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, epressed 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 epress 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 epress 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 epressions 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 California Street, Suite 307, Fremont, CA (510) (510) (fa) info@msforum.org Multiservice Switching Forum 2009

3 Table of Contents 1 SCOPE REFERENCES NETWORK CONFIGURATION TEST CONFIGURATION SCENARIO 4 HANDOVERS SCENARIO 4A HANDOVER WITH S4-SGSN, S1 AND X SCENARIO 4B HANDOVER WITH LEGACY SGSN SCENARIO 4C HANDOVER WITH EHRPD...29 APPENDIX A - S2A CONNECTION ESTABLISHMENT WITH THE DEFAULT PDN...81 APPENDIX B RELEASE RESOURCES IN EPS...82 APPENDIX C - GENERAL PROCEDURE FOR GTP BASED S5/S8 FOR E-UTRAN ACCESS...83 ANNEX ABBREVIATIONS...84 Table of Figures Figure 1 Scenario 4a. Handovers with S4 SGSN... 5 Figure 2 Equipment Configuration for Test S4a-X Figure 3 Message flow for Test S4a-X Figure 4 Equipment Configuration for Test S4a-X Figure 5 Message flow for Test S4a-X Figure 6 Equipment Configuration for Test S4a-X Figure 7 Equipment Configuration for Test S4a-S Figure 8 Message flow for Test S4a-S Figure 9 Equipment Configuration for Test S4a-S Figure 10 Equipment Configuration for Test S4a-S Figure 11 Equipment Configuration for Test S4a-S Figure 12 Message flow for Test S4a-S Figure 13 Equipment Configuration for Test S4a-S Figure 14 Equipment Configuration for Test S4a-S Figure 15 Scenario 4b. Handovers with legacy SGSN Figure 16 Scenario 4c. Handovers with ehrpd access Figure 17 Test Setup Figure 18 EUTRAN to ehrpd Optimized Handover (Active Mode) Figure 19 ehrpd to E-UTRAN Optimized - Active (GTP) Figure 20 ehrpd to E-UTRAN Optimized - Idle Figure 21 ehrpd Pre-registration via E-UTRAN Figure 22 EUTRAN to ehrpd Optimized Handover (Idle Mode) Figure 23 E-UTRAN to ehrpd Non-Optimized Active/Idle Handover via PMIP based S5 and S2a Figure 24 ehrpd to E-UTRAN Non-Optimized using PMIP based S Figure 25 E ehrpd to E-UTRAN Optimized - Active (PMIP) Figure 26 S2a Connection Establishment with the Default PDN Figure 27 Release Resources in EPS Figure 28 General Procedure for GTP based S5/S8 for E-UTRAN Access... 82

4 1 Scope This document describes a number of test cases for the MSF LTE interoperability test event. The testing targets the 3GPP Release 8 Evolved Packet Core interfaces in order to demonstrate multi-vendor interoperability with specific scenarios defined within msf "Physical Scenarios for EPS/LTE Interoperability Testing [1]. The tests described in this document specifically cover Scenario 4, Handover :- o o o o S1-based Handover X2-based Handover MME Handover to S4-SGSN (future) MME Handover to Legacy SGSN (future) 2 References [1] msf Scenarios for EPS / LTE Interoperability Testing [2] msf MSF Architecture for 3GPP Evolved Packet System (EPS) Access Tile Specific references for interfaces/messages are provided along with the message flows in each individual test case. 3 Network Configuration The overall architecture of the network configuration for the testing is defined within msf "MSF Architecture for 3GPP Evolved Packet System (EPS) Access Tile" [2]. A specific network configuration diagram is provided with each test case. 3.1 Test Configuration The provision of a suitable Diameter protocol analyser is required to monitor the Diameter messages on the S6a, S6d, G and R interfaces. The provision of a suitable GTP-Cv2 protocol analyser is required to monitor the GTP messages on the S3, S4, S5, 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.

5 4 Scenario 4 Handovers 4.1 Scenario 4a Handover with S4-SGSN, S1 and X2 This scenario tests intra and inter-rat handovers (inter-rat via the S4-SGSN). The architectures for this scenario is shown in the figure below. GERAN S4 SGSN S3 UTRAN S12 S6d IMS Core S6a HSS P-CSCF IMS UA S1-MME S4 LTE-Uu ENB () MME (a) PCRF R UE IMS UA LTE-Uu X2 S1-U S-11 Gc G LTE-Uu ENB (y) S-GW S10 S5 P-GW SGi X2 S-11 MME (b) S6a ENB (z) Figure 1 Scenario 4a. Handovers with S4 SGSN S4a-X2-1 - IPCAN Session Handover, enb->enb Purpose This test case demonstrates the ability to perform IPCAN Session Handover, enb->enb where the enbs are provided by different vendors. Both enb are associated with the same MME instance Test Setup The equipment is configured as shown in the figure below.

6 IMS Core S6a HSS P-CSCF IMS UA S1-MME LTE-Uu ENB () MME PCRF R UE IMS UA LTE-Uu X2 S1-U S-11 S-GW S5 G P-GW SGi ENB (y) Test Pre-conditions Figure 2 Equipment Configuration for Test S4a-X2-1 Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(y) either manually or through ANR. The UE Attachs to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(y) are in the same tracking area (no MME / SWG relocation). Network Equipment configured in the variants shown below:- Variant 1. LTE UE ENB() ENB(y) MME SGW PGW PCRF HSS Vendor A Vendor B Any Variant 2. LTE UE ENB() ENB(y) MME SGW PGW PCRF HSS Vendor A Vendor B Any Procedure A UE based handover is initiated (from ENB() to ENB(y)). The handover procedure is triggered by the MeasurementReport from the UE Observable Results Pass/Fail criteria Verify that the monitored message sequence is correct.

7 The X2AP: HANDOVER REQUEST shall include the DL Forwarding IE within the E-RAB To be Setup Item IE for which the forwarding of downlink data is to be performed. The X2AP: HANDOVER REQUEST ACKNOWLEDGE should contain a list of E-RABS for which resources have been allocated. The S1AP: PATH SWITCH REQUEST will contain a list of successfully transferred (to ENB(y)) within the E-RAB To Be Switched in Downlink List IE. Verify that the related EPS Bearers remain in place, and that the UE retains the same IP Address Message Flow UE ENB() ENB(y) MME S-GW P-GW 1. RRC: Measurement Report Handover Detection 2. X2AP: HANDOVER REQUEST 4. RRC: RRCConnectionReconfiguration 3. X2AP: HANDOVER REQUEST ACK 5. X2AP: SN STATUS TRANSFER X2U: Data Forwarding 6. RRC: RRCConnection ReconfigurationComplete 7. S1AP: PATH SWITCH REQUEST 8. S11: Update User Plane Request 9. S5: Modify Bearer Request 13. RRC: RRCConnectionReconfiguration 12. S1AP: PATH SWITCH REQUEST ACK 11. S11: Update User Plane Response 10. S5: Modify Bearer Response 14. RRC: RRCReconnectionReconfigurationComplete 15. X2AP: UE CONTEXT RELEASE 16. S1-U: End Marker 17. X2U: End Marker NB Figure 3 Message flow for Test S4a-X2-1 1) The S1-U End Marker (16) can arrive at ENB() before or after the X2AP: UE CONTEXT RELEASE. 2) The message flow has assumed GTP on the S5 interface. Message No Message Name 3GPP Reference 1 RRC: MeasurementReport TS X2AP: HANDOVER REQUEST TS , 13 RRC: RRCConnectionReconfiguration TS

8 5 X2AP: SN STATUS TRANSFER TS S1AP: PATH SWITCH REQUEST TS S11: Update User Plane Request TS S11: Update User Plane Response TS X2AP: UE CONTEXT RELEASE TS Trace Capture The main focus of this test case is the interaction between ENB(), ENB(y) and the MME. It is essential that traces of the messages echanged on the X2 and S1-MME interfaces be captured during the testing and validated against the message flow shown above Known Issues None S4a-X2-2 - IMS Registration Handover, enb->enb Purpose This test case demonstrates the ability to perform IMS Registration Handover, enb->enb where the enbs are provided by different vendors. Both enb are associated with the same MME instance Test Setup The equipment is configured as shown in the figure below. IMS Core S6a HSS P-CSCF IMS UA S1-MME LTE-Uu ENB () MME PCRF R UE IMS UA LTE-Uu X2 S1-U S-11 G S-GW S5 P-GW SGi ENB (y) Figure 4 Equipment Configuration for Test S4a-X Test Pre-conditions Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(y) either manually or through ANR.

9 The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(y) are in the same tracking area (no MME / SWG relocation). The IMS UA on the LTE UE performs a SIP REGISTRATION with the IMS Core. Network Equipment configured in the variants shown below:- Variant 1. LTE UE /IMS UA ENB() ENB(y) MME SGW PGW PCRF HSS IMS Core IMS UA Vendor A Vendor B Any Variant 2. LTE UE /IMS UA ENB() ENB(y) MME SGW PGW PCRF HSS IMS Core IMS UA Vendor A Vendor B Any

10 Procedure A UE based handover is initiated (from ENB() to ENB(y)). The handover procedure is triggered by the MeasurementReport from the UE. Once handover is complete the IMS UA directly connected to the IMS Core attempts to establish a connection to the IMS UA on the LTE UE Observable Results Pass/Fail criteria The IMS UA on the LTE UE enters the Alerting state Message Flow The handover message flow is the same as for Test S4a-X2-1. After handover is complete a SIP INVITE is initiated by the IMS UA directly connected to the IMS Core as shown in the message flow below. UE / IMS UA ENB(y) S-GW P-GW IMS-CORE P-CSCF IMS UA 2. INVITE 3. INVITE 4. INVITE 4. INVITE 4. INVITE 4. INVITE Ringing Ringing Ringing Ringing Ringing Ringing 1. INVITE Ringing Figure 5 Message flow for Test S4a-X Trace Capture A SIP trace from the IMS core should be captured to verify no re-registration takes place Known Issues None S4a-X2-3 - IMS Session Handover, enb->enb Purpose This test case demonstrates the ability to perform IMS Session Handover, enb->enb where the enbs are provided by different vendors Test Setup The equipment is configured as shown in the figure below.

11 IMS Core S6a HSS P-CSCF IMS UA S1-MME LTE-Uu ENB () MME PCRF R UE IMS UA LTE-Uu X2 S1-U S-11 S-GW S5 G P-GW SGi ENB (y) Test Pre-conditions Figure 6 Equipment Configuration for Test S4a-X2-3 Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(y) either manually or through ANR. The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(y) are in the same tracking area (no MME / SWG relocation). The IMS UA on the LTE UE performs a SIP REGISTRATION with the IMS Core. A bi-directional IMS Session is established between the IMS UA on the LTE UE and the IMS UA directly connected to the IMS Core. Network Equipment configured in the variants shown below:- Variant 1. LTE UE /IMS UA ENB() ENB(y) MME SGW PGW PCRF HSS IMS Core IMS UA Vendor A Vendor B Any

12 Vendor A Variant 2. LTE UE /IMS UA ENB() ENB(y) MME SGW PGW PCRF HSS IMS Core IMS UA Vendor B Any Procedure A UE based handover is initiated (from ENB() to ENB(y)). The handover procedure is triggered by the MeasurementReport from the UE Observable Results Pass/Fail criteria The IMS Session remains active, media continues to flow in both directions between the SIP UAs Message Flow The handover message flow is shown in test case S4a-X Trace Capture No trace capture is required for this test case Known Issues None S4a-S IPCAN Session Relocation (MME->MME) Purpose This test case demonstrates the ability to perform IPCAN Session Relocation (MME->MME) where the MMEs are provided by different vendors Test Setup The equipment is configured as shown in the figure below.

13 IMS Core S6a HSS P-CSCF IMS UA S1-MME LTE-Uu ENB () MME (a) PCRF R UE S1-U S-11 G IMS UA X2 S-GW S10 S5 P-GW SGi LTE-Uu S-11 MME (b) S6a ENB (z) Figure 7 Equipment Configuration for Test S4a-S Test Pre-conditions Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(z) either manually or through ANR. An S10 connection has been established between MME(a) and MME(b) The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(z) are in different tracking areas that are not supported by the same MME. The SWG covers both tracking areas (no SWG relocation). Network Equipment configured as indicated below. LTE UE ENB() ENB(z) MME(a) MME(b) S-GW P-GW PCRF HSS Vendor A Vendor B Any Procedure A UE based handover is initiated (from ENB() to ENB(z)). The handover procedure is triggered by the MeasurementReport from the UE.

14 Observable Results Pass/Fail criteria Verify that the monitored message sequence is correct. Verify that the related EPS Bearers remain in place, and that the UE retains the same IP Address Message Flow UE ENB() ENB(z) MME(a) MME(b) S-GW P-GW 1. RRC: Measurement Report Handover Detection 2.S1AP: HANDOVER REQUIRED 3.S10: Forward Relocation Request 4.S1AP: HANDOVER REQUEST 5.S1AP: HANDOVER REQUEST ACKNOWLEDGE 8. RRC: RRCConnection Reconfiguration 7.S1AP: HANDOVER COMMAND 9.S1AP: enb STATUS TRANSFER X2U: Data Forwarding 6.S10: Forward Relocation Response 10. S10 Forward SRNS Contet Notification 11. S10 Forward SRNS Contet Acknowledge 13. RRC: RRCConnection Reconfiguration Complete 12.S1AP: MME STATUS TRANSFER 14.S1AP: HANDOVER NOTIFY 15.S1AP: UE CAPABILITY INFO INDICATION 16. S10 Forward Relocation Complete Notification 17. S10 Forward Relocation Complete Acknowledge 18. S11 Modify Bearer Request 21. S11 Modify Bearer Response 19. S5 Modify Bearer Request 20. S5 Modify Bearer Response 23. X2U End Marker 22. S1-U End Marker NB Figure 8 Message flow for Test S4a-S10-1 1) The message flow has assumed GTP on the S5 interface. Message No Message Name 3GPP Reference 1 RRC: MeasurementReport TS S1AP: HANDOVER REQUIRED TS S10: Forward Relocation Request TS

15 4 S1AP: HANDOVER REQUEST TS S10: Forward Relocation Response TS S1AP: HANDOVER COMMAND TS RRC: RRCConnectionReconfiguration TS S1AP: enb STATUS TRANSFER TS S10: Forward SRNS Contet Notification TS S10: Forward SRNS Contet Acknowledge TS S1AP: MME STATUS TRANSFER TS RRC: RRCConnectionReconfigurationComplete TS S1AP: HANDOVER NOTIFY TS S1AP: UE CAPABILITY INFO INDICATION 16 S10: Forward Relocation Complete Notification 17 S10: Forward Relocation Complete Acknowledge TS TS TS S11: Modify Bearer Request TS S11: Modify Bearer Response TS Trace Capture The main focus of this test case is the interaction between the MME s and the MMEs and the S-GW. It is essential that traces of the messages echanged on the S10 and S11 interfaces be captured during the testing and validated against the message flow shown above Known Issues None S4a-S IMS Registration Relocation (MME->MME) Purpose This test case demonstrates the ability to perform IMS Registration Relocation (MME->MME) where the MMEs are provided by different vendors Test Setup The equipment is configured as shown in the figure below.

16 IMS Core S6a HSS P-CSCF IMS UA S1-MME LTE-Uu ENB () MME (a) PCRF R UE S1-U S-11 G IMS UA X2 S-GW S10 S5 P-GW SGi LTE-Uu S-11 MME (b) S6a ENB (z) Figure 9 Equipment Configuration for Test S4a-S Test Pre-conditions Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(z) either manually or through ANR. An S10 connection has been established between MME(a) and MME(b) The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(z) are in different tracking areas that are not supported by the same MME. The SWG covers both tracking areas (no SWG relocation). The SIP UA on the LTE UE establishes a SIP Registration with the IMS Core. Network Equipment configured as indicated below. LTE UE / SIP UA ENB() ENB(z) MME(a) MME(b) S- GW P- GW PCRF HSS IMS Core P- CSCF SIP UA Vendor A Vendor B Any

17 Procedure A UE based handover is initiated (from ENB() to ENB(z)). The handover procedure is triggered by the MeasurementReport from the UE. Once handover is complete a session establishment attempt is originated from the SIP UA directly connected to the IMS Core to the SIP UA on the LTE UE Observable Results Pass/Fail criteria The SIP UA on the LTE UE enters the alerting state Message Flow The handover message sequence is shown in test S4a-S10-1. The SIP session establishment attempt message sequence is shown in S4a-X Trace Capture A SIP trace from the IMS core should be captured to verify no re-registration takes place Known Issues None S4a-S IMS Session Relocation (MME->MME) Purpose This test case demonstrates the ability to perform IMS Session Relocation (MME->MME), where the MMEs are provided by different vendors Test Setup The equipment is configured as shown in the figure below. IMS Core S6a HSS P-CSCF IMS UA S1-MME LTE-Uu ENB () MME (a) PCRF R UE S1-U S-11 G IMS UA X2 S-GW S10 S5 P-GW SGi LTE-Uu S-11 MME (b) S6a ENB (z) Figure 10 Equipment Configuration for Test S4a-S10-3

18 Test Pre-conditions Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(z) either manually or through ANR. An S10 connection has been established between MME(a) and MME(b) The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(z) are in different tracking areas that are not supported by the same MME. The SWG covers both tracking areas (no SWG relocation). The SIP UA on the LTE UE establishes a SIP Registration with the IMS Core. An IMS Session is established between the SIP UA on the LTE UE and the SIP UA directly connected to the IMS Core. The session results in a bi-directional media flow between the SIP UAs. Network Equipment configured as indicated below.

19 LTE UE / SIP UA ENB() ENB(z) MME(a) MME(b) S- GW P- GW PCRF HSS IMS Core P- CSCF SIP UA Vendor A Vendor B Any Procedure A UE based handover is initiated (from ENB() to ENB(z)). The handover procedure is triggered by the MeasurementReport from the UE Observable Results Pass/Fail criteria The IMS Session remains active, media continues to flow in both directions Message Flow The handover message flow is show in test case S4a-S Trace Capture No trace capture is required for this test Known Issues None S4a-S IPCAN Session Relocation (S-GW->S-GW) Purpose This test case demonstrates the ability to perform IPCAN Session Relocation (S-GW->S-GW) where the S- GWs are provided by different vendors Test Setup The equipment is configured as shown in the figure below.

20 IMS Core S6a HSS P-CSCF IMS UA S1-U LTE-Uu ENB () S-GW(a) PCRF R UE S1-MME S5 S-11 G IMS UA X2 MME S6a P-GW SGi LTE-Uu S1-MME S-11 S5 S1-U S-GW(b) ENB (z) Test Pre-conditions Figure 11 Equipment Configuration for Test S4a-S11-1 Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(z) either manually or through ANR. The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(z) are supported by the same MME. ENB() is in a tracking area covered by SWG(a) and ENB(z) is in a tracking area covered by SWG(b). Network Equipment configured as indicated below. Variant 1. LTE UE ENB() ENB(z) MME S-GW(a) S-GW(b) P-GW PCRF HSS Vendor A Vendor B Any Variant 2. LTE UE ENB() ENB(z) MME S-GW(a) S-GW(b) P-GW PCRF HSS Vendor A Vendor B Any

21 Procedure A UE based handover is initiated (from ENB() to ENB(z)). The handover procedure is triggered by the MeasurementReport from the UE Observable Results Pass/Fail criteria Verify that the monitored message sequence is correct. Verify that the related EPS Bearers remain in place, and that the UE retains the same IP Address Message Flow UE ENB() ENB(z) MME S-GW(a) S-GW(b) P-GW 1. RRC: Measurement Report Handover Detection 2.X2AP HANDOVER REQUEST 4. RRC: RRCConnection Reconfiguration 3.X2AP HANDOVER REQUEST ACKNOWLEDGE 5.X2AP SN STATUS TRANSFER X2U: Data Forwarding 6. RRC: RRCConnection ReconfigurationComplete 7.S1AP PATH SWITCH REQUEST 8.S11 CREATE SESSION REQUEST 9.S5 MODIFY BEARER REQUEST 14. S1AP PATH SWITCH ACKNOWLEDGE 13.S11 CREATE SESSION RESPONSE 15. S11 DELETE SESSION REQUEST 10.S5 MODIFY BEARER RESPONSE 16. S11 DELETE SESSION RESPONSE NB Figure 12 Message flow for Test S4a-S11-1 1) The message flow has assumed GTP on the S5 interface. Message No Message Name 3GPP Reference

22 1 RRC: MeasurementReport TS S1AP: HANDOVER REQUEST TS RRC: RRCConnectionReconfiguration TS X2AP: SN STATUS TRANSFER TS RRC: RRCConnectionReconfigurationComplete TS S1AP: PATH SWITCH REQUEST TS S11: Create Session Request TS S1AP: PATH SWITCH ACKNOWLEDGE TS S11: Delete Session Request TS S11: Delete Session Response TS Trace Capture The main focus of this test case is the interaction between the MME s and the MMEs and the S-GW. It is essential that traces of the messages echanged on the S10 and S11 interfaces be captured during the testing and validated against the message flow shown above Known Issues None S4a-S IMS Registration Relocation (S-GW->S-GW) Purpose This test case demonstrates the ability to perform IMS Registration Relocation (S-GW -> S-GW) the S- GWs are provided by different vendors Test Setup The equipment is configured as shown in the figure below.

23 IMS Core S6a HSS P-CSCF IMS UA S1-U LTE-Uu ENB () S-GW(a) PCRF R UE S1-MME S5 S-11 G IMS UA X2 MME S6a P-GW SGi LTE-Uu S1-MME S-11 S5 S1-U S-GW(b) ENB (z) Figure 13 Equipment Configuration for Test S4a-S Test Pre-conditions Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(z) either manually or through ANR. The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(z) are supported by the same MME. ENB() is associated with S-GW(a) and ENB(z) is associated with S-GW(b). The SIP UA on the LTE UE establishes a SIP Registration with the IMS Core. Network Equipment configured as indicated below. Variant 1 LTE UE / SIP UA ENB() ENB(z) MME S- GW(a) S- GW(b ) P- GW PCRF HSS IMS Core P- CSCF SIP UA Vendor A Vendor B Any

24 Variant 2 LTE UE / SIP UA ENB() ENB(z) MME S- GW(a) S- GW(b ) P- GW PCRF HSS IMS Core P- CSCF SIP UA Vendor A Vendor B Any Procedure A UE based handover is initiated (from ENB() to ENB(z)). The handover procedure is triggered by the MeasurementReport from the UE. Once handover is complete a session establishment attempt is originated from the SIP UA directly connected to the IMS Core to the SIP UA on the LTE UE Observable Results Pass/Fail criteria The SIP UA on the LTE UE enters the alerting state Message Flow The handover message sequence is shown in test S4a-S11-1. The SIP session establishment attempt message sequence is shown in S4a-X Trace Capture A SIP trace from the IMS core should be captured to verify no re-registration takes place Known Issues None S4a-S IMS Session Relocation (S-GW->S-GW) Purpose This test case demonstrates the ability to perform IMS Session Relocation (S-GW->S-GW), where the S- GWs are provided by different vendors Test Setup The equipment is configured as shown in the figure below.

25 IMS Core S6a HSS P-CSCF IMS UA S1-U LTE-Uu ENB () S-GW(a) PCRF R UE S1-MME S5 S-11 G IMS UA X2 MME S6a P-GW SGi LTE-Uu S1-MME S-11 S5 S1-U S-GW(b) ENB (z) Test Pre-conditions Figure 14 Equipment Configuration for Test S4a-S11-3 Network configuration is as per the figure above. EPS Subscriber information for the UE attaching to the network is configured in the HSS. An X2 connection has been established by ENB() and ENB(z) either manually or through ANR. The UE Attach to the LTE Radio Access and Evolved Packet Core via ENB(). The UE is in the ECM-CONNECTED state, with AM bearers that need to be transferred from ENB() to ENB(y). ENB() and ENB(z) are supported by the same MME. ENB() is associated with S-GW(a) and ENB(y) is associated with ENB(z). The SIP UA on the LTE UE establishes a SIP Registration with the IMS Core. An IMS Session is established between the SIP UA on the LTE UE and the SIP UA directly connected to the IMS Core. The session results in a bi-directional media flow between the SIP UAs. Network Equipment configured as indicated below. Variant 1 LTE UE / SIP UA ENB() ENB(z) MME S- GW(a) S- GW(b ) P- GW PCRF HSS IMS Core P- CSCF SIP UA Vendor A Vendor B

26 Any Variant 2 LTE UE / SIP UA ENB() ENB(z) MME S- GW(a) S- GW(b ) P- GW PCRF HSS IMS Core P- CSCF SIP UA Vendor A Vendor B Any Procedure A UE based handover is initiated (from ENB() to ENB(z)). The handover procedure is triggered by the MeasurementReport from the UE Observable Results Pass/Fail criteria The IMS Session remains active, media continues to flow in both directions Message Flow The handover message flow is show in test case S4a-S Trace Capture No trace capture is required for this test Known Issues None.

27 4.2 Scenario 4b Handover with Legacy SGSN This scenario tests intra and inter-rat handovers (inter-rat via the Release 8 legacy SGSN). The architecture for this scenario is shown in the figure below. GERAN SGSN Gn UTRAN Gr IMS Core S6a HSS P-CSCF IMS UA Gn/Gp S1-MME LTE-Uu ENB () MME (a) PCRF R UE IMS UA X2 S1-U LTE-Uu ENB (y) LTE-Uu S-11 S-GW S10 Gc S5 G P-GW SGi X2 S-11 MME (b) S6a ENB (z) Figure 15 Scenario 4b. Handovers with legacy SGSN This scenario was postponed and may be the subject of a future IOT event.

28 4.3 Scenario 4c Handover with ehrpd This scenario tests intra and inter-rat handovers (inter-rat via ehrpd and EUTRAN). The architectures for this scenario is shown in the figures below. Figure 16 Scenario 4c. Handovers with ehrpd access

29 4.3.1 S4c-S1-1 - EUTRAN to ehrpd Optimized Handover (Active Mode) Purpose This test case demonstrates the ability to perform interworking between UE, enodeb provided by Vendor A and MME provided by Vendor B, by performing an EUTRAN to ehrpd Optimized Handover in Active Mode Test Setup HSS SW S6a PCRF RX S1 MME GXc GX GXa UE UU enodeb MME S11 S-GW S5 PDN Gateway SGi IP Services EUTRAN S1-U S103 S2a S6b 3GPP ehrpd S101 STa HSGW PI* 3GPP2 Proy A10 / A11 ean/epcf A12 AN- HRPD BTS HRPD Air Interface UE Figure 17 Test Setup Test Pre-conditions UE is initially attached to the E-UTRAN network. PMIPv6 tunnel on the S5 interface. UE has IPv4 address and/or IPV6 prefi. Data Flows between the UE and the PGW (through enb and SGW). Network Equipment configured as below: UE enb ean/epcf MME SGW PGW HSGW PCRF HSS 3GPP 3GPP2 Vendor A any any any any any any any any Vendor B

30 Note: The focus of this test case is the messaging on the S1 interface Procedure. While connected to EUTRAN, based on the Radio Layer Trigger, initiate a pre-registration procedure with the target ehprd access from the UE. UE initiates the establishment of a new session in the ehrpd system. Additionally, if the testing involves an IMS client then the following test procedures would also apply: Observable Results Pass/Fail Criteria i. IMS registration handover (msf S4a-S12-2) ii. IMS session handover (msf S4a-S12-3) The MME send the PGW address and the associated PAN and the uplink and GRE key along with the HRPD Connection request message to the ehrpd AN over the S101 tunnel. The ean/epcf includes the P-GW address, the associated uplink GRE key received and the indicator that the UE is now operating on the ehrpd radio. The HSGW responds with A11- RRP with the HSGW IP address and GRE Key. The ehrpd ean/epcf sends the HRPD Traffic Channel Assignment (TCA) message in an S101 message to the MME. The S101 message also carries the HSGW IP address and GRE key(s) for data forwarding. The MME forwards the HRPD TCA message embedded in the S101 message to the E- UTRAN which forwards it to the UE over the airlink. E-UTRAN may return downlink IP packets back to the SGW to be sent to the HSGW over the S103 interface. L2 attach is completed - the UE acquires the ehrpd radio. The UE sends a Traffic Channel Completion (TCC) message to the ehrpd ean/epcf. The ehrpd ean/epcf sends an A11-RRQ carrying an Active Start airlink record and the indicator that the UE is now operating on the ehrpd radio to the HSGW. The HSGW responds to the ehrpd ean/epcf with an A11-RRP. If data forwarding via the S103 interface is supported, the HSGW includes an IP address and GRE key to receive forwarded data. The HSGW/MAG sends a PBU(s) to establish a PMIPv6 tunnel(s) with the P-GW(s)/LMA(s) the UE is associated with. The P-GW processes the PBU and updates the binding cache entry for the UE. The same IP address(es) or prefi(es) are assigned to the UE. The P-GW/LMA sends a PBA to the HSGW/MAG, including the IP address(es)/prefi(es) allocated for the UE. The P-GW has requested an IP CAN session, the PCRF responds to the P-GW with a Modify IP-CAN session Ack message. This message includes the Policy and Charging rules provisioned into the P-GW. The ehrpd ean/epcf signals handover completion to the MME to confirm HO completion, and receives an acknowledgement.

31 L3 attach is completed and the UE can now send/receive packets to/from the ehrpd access network. For IMS application, please refer to Pass Fail/Criteria of msf test case S4a-S12-2 and test case S4a-S Message Flow UE enb MME ean/epcf HSGW S-GW PGW 3GPP2 PCRF HSS 0. UE is pre-registered on HRPD 1a. Decision to handover to HRPD 1b. CONN-Req 1b. CONN-Req 1c. CONN-Req (S101) 2a. A11-RRQ 2b. A11-RRP 3. CONN-Req (S101) 4a. Create Forwarding Tunnel 4b. HRPD TCA 5. Indirect Data Forwarding Over S103-U (Optional) 6a. UE acquires HRPD Radio 6b. HRPD TCC 7a. A11-RRQ 7b. A11-RRP 8a. Proy Binding Update 8d. S101 HO Complete Indication/Ack 8b. Proy Binding Update Ack 8c. Modify IP-CAN Session Ack 9. IP Packets Flowing 10. 3GPP EPS Resource Release Figure 18 EUTRAN to ehrpd Optimized Handover (Active Mode) Trace Capture

32 The main focus of this test case is the interaction on S1 reference point and VSNCP message. It is essential that traces of the messages echanged on these issues be captured during the testing and validated against the message flow shown above Known Issues The test details for the procedure involving the IMS client should be updated in the MSF document msf test cases S4a-S12-2 and S4a-S S4c-S1-2 - ehrpd to EUTRAN Optimized Handover (Active Mode - GTP) Purpose This test case demonstrates the ability to perform interworking between UE, enodeb provided by Vendor A and MME provided by Vendor B, by performing an ehrpd to EUTRAN Active Optimized handover via GTP Based S Test Setup Please refer to Section Test Pre-conditions Condition of the UE in ehrpd network UE is initially attached to the ehrpd network - may have an ongoing data session established over HRPD access. Network Equipment configured as below: UE enb ean/epcf MME SGW PGW HSGW PCRF HSS 3GPP 3GPP2 Vendor A any any any any any any any any Vendor B Note: The focus of this test case is the messaging on the S1 interface

33 Procedure UE is registered with HRPD. (Can also have an ongoing data session established over HRPD access). UE initiates the establishment of a new session in EUTRAN network. Additionally, if the testing involves an IMS client then the following test procedures would also apply : i. IMS registration handover (msf S4a-S12-5) ii. IMS session handover (msf S4a-S12-6) Observable Results Pass/Fail Criteria The UE initiates the Attach procedure by transmission of a NAS Attach Request message over tunneling mechanism to the HRPD AN. The HRPD AN selects an MME and TAI. This selection is based on a mapping from the current HRPD reference sector to corresponding MMEs and TAI. An S101 Session ID is used to identify signalling related to that UE on S101. The HRPD AN sends an S101 DT to the MME. MME constructs TAI List for the UE based on the received TAI. If no UE contet for the UE eists anywhere in the network, authentication must be performed. If UE was unknown to the target MME and the old MME, target MME will send an Identity Request to request the UE's IMSI. PDN GW identity is sent from HSS to MME in this step. These messages are tunneled to/from the UE via the HRPD tunneling mechanism and the S101 Direct Transfer capability. If the MME has changed since the last detach, or if it is the very first attach, the MME sends an Update Location to the HSS. The MME selects a Serving GW and sends a Create Session Request (Handover Indication) message to the selected Serving GW. Since the Attach Type is "Handover" Attach, a Handover Indication parameter is included. The Serving GW buffers any downlink packets it may receive from the PDN GW without sending a Downlink Data Notification message to the MME until it receives the Modify Bearer Request message. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request message to the PDN GW. The PDN GW eecutes a PCEF-Initiated IP CAN Session Modification Procedure with the PCRF to obtain any new QoS policy and charging rules for all the active sessions as a result of the handover procedure. The PDN GW returns a Create Session Response message to the Serving GW, with the proper TEIDs and bearer-related information The MME sends an Attach Accept message (and the Bearer Setup Request message if Create Bearer Request message was received) to the UE over the S101 interface. S-TMSI is included if the MME allocates a new S-TMSI. TAI List for the UE is included in the Attach Accept message. The UE sends the Attach Complete message (and the Bearer Setup Response message) over the S101. The HRPD AN forwards the Attach Complete message (and the Bearer Setup Response message) to the MME. If Create Bearer Request message was sent by the Serving GW, the MME sends a Create Bearer Response message to Serving GW. If Create Bearer Request message was sent by the PDN GW, the Serving GW sends a Create Bearer Response message to PDN GW. Upon completion of the E-UTRAN Attach procedure, UE switches over to EUTRAN.

34 UE performs the NAS service request procedure. The MME sends S1-AP Initial Contet Setup Request message to the enodeb. The enodeb performs the RRC radio bearer establishment procedure. The enodeb sends the uplink data to the Serving GW address and TEID provided. The enodeb sends an S1-AP message Initial Contet Setup Complete to the MME. The MME sends a Modify Bearer Request message to the Serving GW. The Serving GW is now able to transmit downlink data towards the UE. The Serving GW sends a Modify Bearer Response to the MME. MME sends HO complete to the HRPD AN, so that it can release resources. The HRPD resources may be released according to the 3GPP2 specific release mechanism. The P-GW shall initiate the Resource Allocation Deactivation Procedure in HRPD network. For IMS application, please refer to Pass Fail/Criteria of msf test case S4a-S12-5 and test case S4a-S Message Flow UE ean/epcf enb MME HSGW S-GW PGW 3GPP2 HSS PCRF 1. UE is preregistered on HRPD 2. Decision to handover to eutran 3. Attach Req 5. Auth 4. Direct Transfer (S101 Session ID, Attach Req, etc) 5. Direct Transfer (S101 Session ID, Authentication) 7. Create Session Request 5. Authentication 6. Location Update and Subscriber Data Retrieval 8. Create Session Request 9. PCEF Initiated IP-CAN Session Modification Procedure 10. Create Session Response (A) 13. Attach Accept 12. Direct Transfer (S101 Session ID, Attach Accept) 11. Create Session Response 14. Attach Complete 15. Direct Transfer (S101 Session ID, Attach Complete) 18. LTE Radio ON 16. Create Bearer Response 17. Create Bearer Response (B) 19. RRC Conn Request 21. RRC RB establishment 20. Initial UE contet Setup Req 22. Initial UE contet Setup Complete 23. Modify Bearer Request 25. HO Complete 24. Modify Bearer Response 26. Release of HRPD Resources 27. P-GW resource allocation deactivation Figure 19 ehrpd to E-UTRAN Optimized - Active (GTP)

35 Trace Capture The main focus of this test case is the interaction on S1 Message. It is essential that traces of the messages echanged on these issues be captured during the testing and validated against the message flow shown above Known Issues The message echange between the UE and epcf/ean will be changed once 3GPP has decided their actual name. The test details for the procedure involving the IMS client should be updated in the MSF document msf test cases S4a-S12-5 and S4a-S S4c-S1-3 - ehrpd to EUTRAN Optimized handover (Idle mode) Purpose This test case demonstrates the ability to perform interworking between UE, enodeb provided by Vendor A and MME provided by Vendor B, by performing an ehrpd to EUTRAN Optimized handover in Idle State Test Setup Please refer to Section Test Pre-conditions Condition of the UE in ehrpd network The UE is registered with HRPD and is in dormant mode. Network Equipment configured as below: UE enb ean/epcf MME SGW PGW HSGW PCRF HSS 3GPP 3GPP2 Vendor A any any any any any any any any Vendor B Note: The focus of this test case is the messaging on the S1 interface Procedure

36 UE is registered with HRPD and is in dormant mode. UE initiates the establishment of a new session in EUTRAN network Observable Results Pass/Fail Criteria UE becomes active in HRPD and sends Attach Request message to HRPD access node carried on HRPD message to trigger the attach procedure to E-UTRAN. The HRPD AN selects an MME and TAI. This selection is based on a mapping from the current HRPD reference sector to corresponding MMEs and TAI. An S101 Session ID is used to identify signaling related to that UE on S101. The HRPD AN sends an S101 DT to the MME. MME constructs TAI List for the UE based on the received TAI. If no UE contet for the UE eists anywhere in the network, authentication must be performed. If UE was unknown to the target MME and the old MME, target MME will send an Identity Request to request the UE's IMSI. PDN GW identity is sent from HSS to MME in this step. These messages are tunnelled to/from the UE via the HRPD tunnelling mechanism and the S101 Direct Transfer capability. If the MME has changed since the last detach, or if it is the very first attach, the MME sends an Update Location to the HSS. The MME selects a Serving GW and sends a Create Session Request (Handover Indication) message to the selected Serving GW.Since the Attach Type is "Handover" Attach, a Handover Indication parameter is included. The Serving GW buffers any downlink packets it may receive from the PDN GW without sending a Downlink Data Notification message to the MME until it receives the Modify Bearer Request message. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request message to the PDN GW. The PDN GW eecutes a PCEF-Initiated IP CAN Session Modification Procedure with the PCRF to obtain any new QoS policy and charging rules for all the active sessions as a result of the handover procedure. The Serving GW initiates a Gateway Control Session Establishment Procedure with the PCRF to obtain the rules required for the Serving GW to perform the bearer binding for all the active sessions the UE may establish as a result of the handover procedure. The Serving GW creates a new entry in its EPS Bearer table and sends a Proy Binding Request message to the PDN GW. The PDN GW eecutes a PCEF-Initiated IP-CAN Session Modification Procedure with the PCRF to obtain the rules required for the PDN GW to function as the PCEF for all the active IP sessions the UE has established with new IP-CAN type. The Serving GW returns a Create Session Response message to the new MME. The Create Bearer Request message may be sent together with the Create Session Response message. The MME sends an Attach Accept message (and the Bearer Setup Request message if Create Bearer Request message was received) to the UE over the S101 interface. S-TMSI is included if the MME allocates a new S-TMSI. TAI List for the UE is included in the Attach Accept message. The UE sends the Attach Complete message (and the Bearer Setup Response message) over the HRPD AN tunnelling mechanism. The HRPD AN forwards the Attach Complete message (and the Bearer Setup Response message) to the MME. If Create Bearer Request message was sent by the PDN GW, the Serving GW sends a Create Bearer Response message to PDN GW. The UE synchronises with the target cell and sends a TAU message to the MME.

37 The MME sends a Modify Bearer Request message to the Serving GW. If the Serving GW receives any downlink data or it had already buffers any downlink data, it is now able to send the Downlink Data notification to MME to trigger paging procedure. The Serving GW acknowledges a Modify Bearer Response to the MME. The MME returns a TAU Accept message to the UE. HRPD resources are released as applicable, using the PDN GW initiated release procedure Message Flow UE ean/epcf enb MME HSGW S-GW PGW 3GPP2 HSS PCRF 1. HRPD Radio On 2. UE decided to Handover to EUTRAN 3. Attach Request 4. Refer to Step 4 17 of ehrpd to E-UTRAN Optimized - Active (GTP) 5. LTE Radio On 6. TAU Request 9. TAU Accept 7. Modify Bearer Request 8. Modify Bearer Response 10. Release of HRPD Resource Figure 20 ehrpd to E-UTRAN Optimized - Idle Trace Capture The main focus of this test case is the interaction on S1 message. It is essential that traces of the messages echanged on these issues be captured during the testing and validated against the message flow shown above Known Issues The message echange between the UE and epcf/ean will be changed once 3GPP has decided their actual name S4c-S ehrpd Pre-registration via E-UTRAN Purpose This test case demonstrates the ability to perform interworking between UE and MME provided by Vendor A and ean provided by Vendor B, by performing an ehrpd Pre-registration via E-UTRAN.

38 Test Setup Please refer to Section Test Pre-conditions Condition of the UE in EUTRAN network UE is initially attached to the E-UTRAN network. PMIPv6 tunnel on the S5 interface. UE has IPv4 address and/or IPV6 prefi. S101 signaling relationship eists between MME and ean/epcf. Data Flows between the UE and the PGW. Network Equipment configured as below: UE enb ean/epcf MME SGW PGW HSGW PCRF HSS 3GPP 3GPP2 Vendor A any any any any any any any any Vendor B Note: The focus of this test case is the messaging on the S101 interface Procedure While connected to EUTRAN, based on the Radio Layer Trigger, initiate a pre-registration procedure with the target ehprd access from the UE. UE initiates the establishment of a new session in the ehrpd system Observable Results Pass/Fail Criteria A11 RRQ message should contain an indication that the access is occurring through S101 tunnel. The 3GPP server queries the HSS and returns the P-GW address to the ehrpd system. The HSGW stores the PGW-IP address and default APN, QoS profile and other user contet information received from 3GPP /HSS server. The VSNCP-Configure-Request sets the Attach Type to handoff. The UE includes the IP address(es) it obtained via LTE in the VSNCP-Configure-Request.