Wayne Cutler
MSF CTO
10th October 2012
`
`
`
Founded in 1998
Open consortium of telecommunications
companies
p
((mix of large
g operators,
p
, large
g
vendors, niche suppliers, test tool
suppliers et al)
See www.msforum.org
¾
¾
¾
Focuses on developing meaningful physical
implementations of standards
Organises large-scale interoperability events to test and
validate standards in implementations of interest to
major carriers
See http://www.msforum.org/interoperability/GMI.shtml
http://www msforum org/interoperability/GMI shtml
for details of all MSF IOT events
¾ Operators and Equipment Vendors that participate in Open
Interoperability Events learn how multivendor nextgeneration products and networks will interoperate in the
real world.
¾ Must be “relevant” – i.e. related to technology that is at the
right point in its development cycle
¾ That information translates into several financial benefits:
¾ Reduced time to market for deployment of interoperable
solutions and decreased costs and resources to resolve
interoperability issues
¾ Operators get a better understanding of the maturity of a
technology and gain insight into “best in class” products
¾ Improved protocol documentation through facilitating
clarifications in the tested standards via feedback to the
appropriate SDOs
¾ Thoroughly
g y evaluated architectural framework for cooperatively
p
y
designing end-to-end networking solutions
¾ MSF has previously run two LTE related IOT events
¾ LTE/EPC IOT in March 2010
¾ VoLTE IOT in September 2011
¾ RCS VoLTE IOT builds on the previous LTE related IOTs
¾ MSF partnered with ETSI & GSMA to jointly organise this
event
¾ Reflects the common focus of MSF & ETSI TC-INT
¾ Endorses a number of GSMA PRDs for RCS & VoLTE
¾ Test plans sourced from each of the partner organisations
¾ Event scope consists of two main scenarios:-
¾ Scenario 1 - RCS VoLTE in a Home/Single Network
¾ Scenario 2 - RCS VoLTE for Roaming & Interconnect
¾ Each scenario is broken down into a number of sub
subscenarios
¾ Scenario
S
i 2 has
h a number
b off configurations
fi
ti
to
t reflect
fl t
roaming/interconnect differences
¾ Test Scenarios document is publicly available at
http://www.msforum.org/interoperability/RCS%20Vo
LTE%20Scenarios%202012-07-16
LTE%20Scenarios%202012
07 16.pdf
pdf
`
`
A single instance of the RCS VoLTE architecture was created
using components from different vendors.
Four sub
sub-scenarios
scenarios
◦ IPCAN session establishment/disestablishment and SIP registration (to
IMS),
◦ SIP voice session establishment & interaction with IMS MMTEL AS
◦ RCS Services
◦ SIP multimedia session establishment & interaction with IMS MMTEL AS.
`
Focused
Foc
sed on testing interoperabilit
interoperability of the ffunctionality
nctionalit as
profiled by GSMA PRDs IR.92, IR.94, IR.90, IR.67 and the RCS
Services and Client Specification.
IMS Core
Ut
MMTel / RCS
Application
Servers
Ut
Mr’
MRF
Sh
I
S
C
Cx
HSS
Cx
Sh
P-CSCF
Mw
I/S-CSCF
Rx
S6a
DRA
UE
ENUM
S6a
Rx
IMS UA
Gx
PCRF
LTE-Uu
Gx
MME
UE
SecGW
LTE-Uu
IMS UA
S1-MME
S11
S1-U
eNodeB
S-GW
S5
P-GW
SGi
Mr
ENUM
Server
`
`
`
`
`
`
Tested roaming and interconnect between 2 PLMNs.
For roaming
roaming, the local breakout model with visited P
P-CSCF
CSCF
and home operator applications was tested.
There were the same 4 sub-scenarios as for Scenario 1.
Also a number of different configurations.
g
This scenario focused on testing interoperability of the
functionality as profiled by GSMA PRDs IR.65, IR 88, IR.92,
IR.94, IR.90, IR,67 and the RCS Services and Client
Specification.
Specification
An IPX provided the interconnect network between the 2
PLMNs.
IMS Core
MMTel / RCS
Application
Servers
Ut
Mr’
MRF
Sh
I
S
C
Cx
HSS
Cx
Sh
P-CSCF
Mw
Mr
I/S-CSCF
Mx
IBCF/TrGW
Rx
PLMN-A
S6a
DRA
S6a
Rx
Ici/Izi
ENUM
Gx
PCRF
Gx
MME
ENUM
Server
IPX
ENUM
S1-MME
UE
SecGW
LTE-Uu
IMS UA
S11
S1-U
PLMN-A
S-GW
eNodeB
S5
P-GW
PLMN-B
ENUM
SGi
Ici/Izi
IMS Core
MMTel / RCS
Application
Servers
Ut
Mr’
MRF
Sh
I
S
C
Cx
HSS
Cx
Sh
P-CSCF
Rx
S6a
DRA
S6a
Rx
Gx
G
PCRF
Gx
MME
UE
S1-MME
SecGW
LTE-Uu
IMS UA
S11
S1-U
eNodeB
S-GW
S5
P-GW
SGi
Mw
I/S-CSCF
Mr
Mx
IBCF/TrGW
PLMN-B
¾
¾
¾
¾
¾
¾
¾
¾
¾
IR.65 : IMS Roaming & Interworking Guidelines
IR.88 : LTE Roaming Guidelines
IR 92 : IMS Profile for Voice and SMS
IR.92
IR.90 : RCS Interworking Guidelines
IR.67: DNS/ENUM Guidelines for Service Providers &
GRX/IPX
IR.58: IMS Profile for Voice over HSPA
IR.94: IMS profile for Conversation Video Service
RCS-e
RCS
e – Advanced Communications: Services and Client
Specification: Version 1.2.1
Rich Communication Suite 5.0 Advanced Communications:
Services and Client Specification
p
¾ Scenario 1a – ETSI TS 103 029
¾ Scenario 1b – MSF2012.069
¾ Scenario 1c – MSF2012.070
MSF2012 070 - based on GSMA RCS-e test
cases, http://www.gsma.com/rcs/product-specifications/rcse-specifications/
¾ Scenario 1d – MSF2012.071
MSF2012 071
¾ Scenario 2a - MSF2012.072/027 & ETSI TS 186 011-02
¾ Scenario 2b – MSF2012.074 & ETSI TS 186 011-02
¾ Scenario 2c – ETSI TS 102 901 v1.1.1/2.1.1
¾ Scenario 2d – MSF2012.076/077
¾ The event sought to reflect real world deployment strategy in
terms of testing between “blocks”
¾ Typical blocks could be
¾ UE/Client
¾ eNB
¾ EPC
¾ DRA
¾ PCRF
¾ IMS Core
¾ MMTEL/RCS AS
¾ IBCF/SBG etc
due to less
¾ This also enabled stabler configurations
g
swapping of elements
¾ Within certain constraints, equipment could be sited in a
host lab or connect in via VPN connection to that lab
¾ Facilitates vendor participation and reduces the cost or
participation
¾ Ues & eNBs must be in a host lab
¾ All observable interfaces must be traceable by the
monitoring equipment in a host lab
¾ Additional background activity to perform DIAMETER
conformance testing
¾ STF450 validating ETSI Conformance Test Suites (TS 101
580-3[Rx] & TS 101 601-3 [Gx] )
¾ Tools developed by STF 450 enable automatic confpormance
checking of traces taken during the IOT
¾ In addition, tools previously developed by other STFs enable
conformance checking of SIP messages
¾ Two STF experts were in attendance at the event to check
conformance on :¾ SIP (Mw, Ici, ISC) for test cases in TS 186 011
¾ DIAMETER ((Rx)) for test cases in TS 103 029
V LTE RCS IOT E
VoLTE
Event 2012
Hosted By:
Participants:
Observers:
Sintesio
LTE UE
VoLTE Client
RCS Client
eNodeB
EPC (MME+SGW+PGW)
HSS
3rd party
Radisys
Telekom
Slovenia
Cisco
PCRF
P-CSCF/IMS-ALG
Tekelec
MMTel AS
MRF
Genband
RCS IM/Chat Server
IBCF-TrGW
Genband
I/S-CSCF
RCS Video Share AS
DRA
IPX
ENUM
Monitoring Equipment
D2Tech
CMCC
CMCC
Cisco
Iskratel
Iskratel
Iskratel
Radisys
Genband
Iskratel
Genband
Aicent
Neustar
JDSU
CMCC
D2Tech
D2Tech
Telekom
Slovenia
Cisco
Cisco
Ulticom
CMCC
CMCC
CMCC
Metaswitch
Iskratel
Genband
Iskratel
Ulticom
Tekelec
Acme Packet
Acme Packet
CMCC
Genband
Genband
Metaswitch
Genband
Acme Packet
Tekelec
Aicent
Neustar
JDSU
Acme Packet
LTE UE
VoLTE Client
RCS Client
eNodeB
EPC
(MME+SGW+PGW)
3rd party
(local)
Radisys (local)
Telekom
Slovenia (local)
Cisco (Italy)
HSS
PCRF
P-CSCF/IMS-ALG
I/S-CSCF
MMTel AS
MRF
RCS Video Share
AS
CS IM/Chat
Ch
RCS
Server
Tekelec (USA)
Cisco (Italy)
Cisco ((Italy)
y)
Genband
(local)
Radisys (local)
Genband
(local)
G b d
Genband
(local)
IBCF-TrGW
DRA
ENUM
IPX
Monitoring
Equipment
Ulticom (local)
Neustar (USA)
Aicent (USA)
JDSU (local)
Kit (Location)
D2Tech (local)
D2Tech (local)
D2Tech (local)
Iskratel
s ate
(Slovenia)
Iskratel
(Slovenia)
Iskratel
((Slovenia))
Iskratel
(Slovenia)
Iskratel
(Slovenia)
Metaswitch
(local)
Iskratel (local)
Metaswitch
(local)
`
`
`
The two host sites were connected via IPX
(L2TP from Sintesio, IPSEC fromCMCC),
Remote vendor equipment
q p
was (mostly)
y
connected via L2 VPNs using L2TP,
In one case,, an IPSEC connection was used for
vendor equipment
`
VoLTE calls successfully demonstrated with
Supplementary Services
◦ Intra PLMN (Slovenia and Beijing)
◦ Inter PLMLN (between Slovenia and Beijing) _ using
IPX
`
`
RCS Ch
Chat successfully
f ll demonstrated
d
d
RCS File Transfer successfully demonstrated
`
`
`
`
`
Multi-vendor interoperability of UE, eNodeB,
EPC, IMS Core, AS, DRA and PCC.
Voice calls established using dedicated bearer
(QCI 1),
(QCI=1),
Voice / Video calls established using
dedicated bearers (QCI=1
(QCI 1 & QCI=2)
QCI 2),
No issues with GTP,
DIAMETER was observed to be much more
stable than in VoLTE 2011 event,
`
`
`
Use of a DRA reduced connections and
simplified Diameter message routing. DRAs
were also shown to provide interworking
between different transport layer protocols
and act as a DIAMETER “firewall”.
Some DIAMETER AVPs incorrectly tagged as
mandatory,
Issue with Rx conformance on 1 P
P-CSCF
CSCF at
registration.
`
`
`
`
`
Sh interface not supported by all ASs.
Ut interface was supported and tested by
UE/AS.
Issues with 3rd party registration relating to
IFCs – but these were resolved.
SCTP transport was not used by all DIAMETER
elements – DRA did TCP/SCTP i/w.
SIP fragmentation was seen when the MTU
size exceeded 1500 bytes, which was solved
UDP
by use of TCP rather than UDP.
`
`
`
`
Most implementations were 3GPP R8 based.
SIP syntax issues encountered on some
implementations.
Configuration issues were reduced due to the
strategy of testing “blocks”. In some cases,
reconfiguration was necessary to enable
testing when fixes were needed.
Issues encountered with VoLTE client on
some lap tops believed to be related to OS.
`
`
`
`
`
Latency in the test network due to remote
location of equipment. Impacted on set-up
set up
times and media quality.
Transcoding transrating and DTMF collection
Transcoding,
demonstrated via MRF.
MMTEL services demonstrated via AS (OIP,
(OIP
OIR, TIP, CFU, ICB, OCB, CFNR, CW, CH)
RCS Chat & FT demonstrated
demonstrated.
Issue with SIP OPTIONS transiting an IMS core.
`
`
`
`
`
`
Complete the event
Analyze the results for input into a White Paper
Publish the event White Paper – target date of mid
November following a drafting session in the MSF Q4/12
meeting in Singapore Oct 30th to November 1st
Send liaisons to partner organizations
Present results /findings at industry events in Asia,
Asia
Europe and North America,
Consider next steps / future testing.
Questions / Comments