About VoLTE Testing
VoLTE, Voice over LTE is an IMSIMS-based specification. Landslide VoLTE Feature and IMS VoLTE CN Emulation provides SIP and RTP-based Voice over IP capabilities to Landslide’s LTE solution.
The Landslide VoLTE implementation supports testing of in LTE ePC as a whole or in part with a two-arm configuration. In addition, the implementation also supports one-arm configuration with the IMS Core Network and combined ePC / IMS CN for VoLTE support.
See also:
Testing Combined ePC and VoLTE IMS CN (Two-Arm Test)
Landslide VoLTE testing is supported with MME Nodal and SGW Nodal test cases.
UE emulates SIP Users/Endpoints:
- Multiple SIP Endpoints per Mobile Subscriber
- Multiple Media streams per SIP Endpoint
- Each UE is able to originate or terminate calls
IMS Node:
- IMS Node emulates Server side: P-CSCF and SIP Endpoints
- Provides Rx control triggers
Testing VoLTE IMS CN (One-Arm Test)
Landslide VoLTE testing is supported with MME Nodal and SGW Nodal test cases.
UE emulates SIP Users/Endpoints:
- Multiple SIP Endpoints per one Mobile Subscriber
- Multiple Media streams per one SIP Endpoint
- Each UE is able to originate or terminate calls
| NOTE: IMS Node to be used for back-to-back testing. |
Test Terminologies
Public/Private User identity and their Relationship
| Public User Identity |
Each IMS user is allocated one or more Public User Identities
|
| Registered Public User Identity |
Implicitly registered Public User Identities
|
| Private User Identity |
Each IMS user is assigned a Private User Identity
|
Public and Private User identity Relationship
- An IMS subscriber is assigned one or more Private User Ids which map to Public User Ids
- Multiple Private User Ids may map to the same Public User Id or Ids
- In the network the HSS and S-CSCF store and correlate Private and Public User Ids
- For UMTS/LTE only one Private User Id is stored in the smart card
The following illustrates an The relation of a shared Public User Identity (Public-ID-2) and Private User Identities
The subscriber is allocated at least one Public User Identity by the home network operator
-
Public User Identities may be SIP or tel URIs
-
At least one Public User Id must be a SIP URI
-
For each tel URI there is at least one alias SIP URI
-
Public User IDs may be shared across and registered by multiple UEs using different Private User IDs and contact addresses
Multiple smart cards with different Private User Ids may be used in different IMS terminals (UEs)
Session Description Protocol (SDP)
SDP is a textual format used to describe multimedia sessions (RFC 2327). A session description contains relevant information for the remote user to join the multimedia session.
- SDP Offer/Answer model (RFC 3264) provides a two-way session description exchange or negotiation.
- The Offering user sends a session description (the Offer), the remote user generates a new session description (the Answer) and sends it to the Offering user.
- The Offer/Answer exchange provides both users with a common view of the multimedia session, at a minimum media formats and transport addresses.
- Additional information exchanged may include, cryptographic keys and algorithms.
The following illustrates an example SDP.
Session Initiation Protocol (SIP)
SIP (defined in RFC 3261) is used to create, modify and terminate multimedia sessions. Key function is to deliver session description information to the user at their current location using SDP
SIP for IMS includes many extensions for 3GPP support:
- Binding of SIP public URI to UE’s IP address/host name during REGISTRATION
- Support for instant messages and handling of subscription events
- Delivery of session description information to the user at their current location
Real-time Protocol (RTP)
A Transport Protocol for Real-time Applications defines RTP (RFC 3550), for end-to-end transport of real-time data, such as audio and video over multicast or unicast networks.
RTP also defines an independent control protocol (RTCP) offering data delivery monitoring and minimal control capabilities (RTCP is optional under the VoLTE implementation).
VOLTE Call Patterns and Phonebook
The following defines the phonebook mapping is based on VoLTE functionality patterns in MME and SGW Nodal Test Cases.
|
NOTE: The phonebook mapping is the same whether IMS Node Type is local or remote. The configurations on Nodal and Node sides must match the call pattern, either for All Originate, All Terminate, OTOT, or TOTO. Add/remove video functionality is triggered and controlled by SIP Originate Subscriber/Endpoint so that Terminate relies on the received SIP signaling messages. |
|
VoLTE > UE Pane |
Phonebook |
|||||||
| Enable Mobile To Mobile | Functionality Pattern |
SIP Subscriber and SIP Endpoint Originating and Terminating Mapping |
||||||
| Not Selected | All Originate |
When originating a call maps the Phonebook for SIP Phonebook as follows.
|
||||||
| OTOT |
The Originate/Terminate maps the Phonebook for SIP Subscriber and SIP Endpoint as follows.
|
|||||||
| TOTO |
The Originate/Terminate maps the Phonebook for SIP Subscriber and SIP Endpoint as follows.
|
|||||||
| All Terminate |
The all Terminate functionality maps the Phonebook for SIP Subscriber and SIP Endpoint as follows.
|
|||||||
| Selected | OTOT |
The Originate/Terminate maps the Phonebook for SIP Subscriber as follows.
|
||||||
| TOTO | The Terminate/Originate maps the Phonebook for SIP Subscriber as follows.
|
|||||||
|
NOTES: The Mobile to Mobile testing in SGW Nodal TC establishes calls between the Mobile Subscribers belonging to the test case (that is, subscribers populated in the phonebook within the Test Case). To test mobile to mobile call between two SGW Nodal test cases the SIP Subscribers in one test case must be configured as SIP Endpoints in the other test case and vice versa. Configure the phonebook for Mobile to Mobile calls as follows.
For example: Set up test cases to for Mobile to Mobile calls as follows:
|