Deployment Options With Hosted RCS

10/27/2014– strictly confidential, confidential, internal, public – 1

DEPLOYMENT OPTIONS WITH HOSTED RCSSEBASTIAN SCHUMANN, SLOVAK TELEKOM29. October 2014. Berlin, Germany

SCOPE

What are the deployment options with hosted RCS solutions - ST rollout in Q2 2014

Evaluating the pros and cons of cloud solutions in RCS services

Is the technology finally ready

Case study

October 2014, Berlin, GermanySebastian Schumann: “Deployment options with hosted RCS”, 7th annual Rich Communication 2

@s_schumann

Feedback is welcome, get in touch during/after the event!

SLOVAK TELEKOM

Former fixed/mobile incumbent (merger in 2010), Zoznam, Posam, DIGI

Diverse service portfolio (fixed/mobile network and communications services, Internet access + content, data services, CPE, ICT services (data center + cloud), radio/TV broadcasting, call center services, …)

The major shareholder is Deutsche Telekom AG.

Successful deployments in SEE as well as in DT group:

One of the biggest national-wide deployment of NGN technology in Europe in 2004, whole city migrated to all-IP NGN in 2007

Fixed network IMS migration to be finished in 2014

Leader in IPTV, offering hybrid sat TV (s. 2009) & OTT app (s. 2012)

Extensive FTTx deployments (360k households)

First nation-wide 4G/LTE network (s. 2013)October 2014, Berlin, GermanySebastian Schumann: “Deployment options with hosted RCS”, 7th annual Rich Communication 3

Slovak Telekom Group is the telecoms market leader in Slovakia

EXPECTATIONS

Honest & realistic dissemination of status quo from 1st hand

Deployed RCS 5 in H1/2014

Go-live 30. June 2014

My role: local technical manager for design and implementation

This presentation is going to be subjective in parts

Don’t judge me on that – this is why I am here

Experience with IMS, various RCS deployment options, messaging strategies in ST

Joyn as service needs to do move forward quickly, I will summarize on our fast execution & seen future potential

Focus on a bit of “How”, a lot of “What’s could be next” – not on “Why”


HOW?HOSTED JOYN SERVICE IMPLEMENTATION IN SLOVAK TELEKOM

Hosted RCS 5 (Blackbird) service provided by Jibe Mobile

No local NT implementation (no IMS/SBCs etc.)

Private cloud connected via public Internet

Jibe hub for interconnection

No local interconnection

Jibe hub provides technical interconnect with all Jibe clouds

Offers standard NNI

Launched with full set of services on localized Android and iOS apps

Messaging, file transfer, location share

High definition voice & video (much better quality than telephony)

Go live and operation without major hick-ups or failures


Bottom line

The implementation and joint work with Jibe was a success.

PRO’S & CON’S OF CLOUD DEPLOYMENTSHIGH-LEVEL

Fast

Cheap

None


PRO’S CON’S

PRO’S CON’S

PRO’S & CON’S OF CLOUD DEPLOYMENTSDETAILED

No or insignificant CAPEX, OPEX driven

Risk free: Can be killed early if KPI’s not met

All in one integrated solution (in our case)

Simpler interconnect

Easier accreditation

Jibe platform has much more features than usual local on-IMS deployments

No local IMS integration, deployment etc.

No local IMS deployment

VoLTE dependency (multiple “IMS”)

Regulatory or legal challenges (e.g. LI, data)

Large scale deployments may be more expensive

Potential vendor lock-in (UNI for apps, infrastructure)


LOOKING BACK TO 2012POINTS I RAISED LAST TIME AT THIS EVENT

“

joyn as “chat for mobile phones” is not going to convince alone

RCS as a platform may enable interesting use cases, if the concept is done right

joyn as platform/enabler not a bad idea as such, but it is not the new SMS!

What can Telco’s do once they have IMS or RCS infrastructure (for whatever reason)

Wrong: Look at what we can do with it. Create need or technical motivation. Joyn

Technology driven services and features are wrong!

Northbound integration of IMS service layer should not be an option, but a must!

… and should be done with Web 2.0 technologies/protocols

Integration is important (internally as well as opening for external access)

“


WHAT’S NEXT?

Joyn as a service started “not too successful”

“Too little, too late” – we all know about that, no need to repeat

Time moved on – simply put: The world is different in 2014!

Joyn as a platform may have a potential

That may be able to help the service

This is a case study partially taking our innovative platform as an example

It hopefully encourages others that got Joyn (one way or another) to quickly stop lamenting & see what to do next

Reach small fragment of customers that has Joyn, but much more importantly expose new functions

May not be best or cheapest option, but better than not progressing at all

May bring up to date APIs, integrated with some back-end systems


ONE PROBLEM WITH JOYN, AND HOW TO WORK AROUND ITUNIVERSAL IS GOOD, UNLESS YOU NEED BETTER


GOOD BETTER

WEBRTC TO THE RESCUE

No.

Maybe…

… but not really …

… and not only!


“BETTER” SOON TO BE THE DEFAULTWEBRTC CONTRIBUTES TO THE EVOLUTION

WebRTC is not so much about technology, but “embedded contextual communications” in the web/an app

No ubiquity needed

When I am on amazon.com I do not expect to be able to talk to Billa or the police through that website

When I am inside the IKEA app I do not expect to order a Pizza (maybe meat balls though )

Value shift from solving connectivity in the 1900s to solving actual problems

I am connected to a service the minute I enter their URL, RTC needed if it helps solving the problem

An entire industry (us!) mapped in a service feature

Known networks use known methods, unknown connections will not connect from the address book

Searching for business Results in Google Connect right from within the browser

Mobile entry point for “longer customer relation” is an app Soon to have inbuilt communication


THE DILEMMA

P2P communicating using stand-alone tools (integrated + apps) is most likely not going to evolve

Universal lowest common denominator service is here (telephony, SMS), not yet another one needed

Stand-alone app “market” saturated

Best ways for reaching existing known contacts established

Services today are defined by the front-end design/experience, the back-end technology is irrelevant for users

Joyn is built by technologists, mainly due to belief in IMS for everything and need to standardize everything

Does not mean defined NNI or operator bits and pieces not useful at all, but could be achieved better

How? There are two options

Give up (do nothing or think Joyn is enough for the next years)

Look forward (and make finally use of state of the art web technologies)


USE YOUR PLATFORM

If you deployed Joyn hopefully you did not just build a complex system, but also a bucket full of interesting APIs

SIP ISC interface is no API! We are talking HTTP REST + JSON!

Jibe brings many APIs out of the box, access to all the capabilities

Joyn by Jibe on iOS makes already use of these APIs certain assurance for us that it will not be forgotten

Benefits

Integrate capabilities elsewhere and focus on the new capabilities as enabler to build new services

Does not mean integrate RCS as a service itself, but rather some capabilities into web services to enhance those

Justification of new investments, use them as enabler to get new capabilities to integrate anywhere

Important footnote

I do not mean to buy an RCS platform for this purpose, rather utilizing enabler features that you get anyways

Web services do not need Telco back-ends most of the time and may often be solved better

If you have them though there is no need to ignore and neglect them


WE ARE DOGFOODING!

Not just talking API, but use it right away: Work on a use case and traverse it into reality within a couple of days (yes, literally!)

Use case development: Sample marketing campaign by using Joyn as video distribution platform

Celebrity records videos that are distributed to fans using Joyn

Reaching (optimistically) thousands of end points can’t shouldn’t be done manually

Using the Jibe platform API we were able to fully automate the process

Ridiculously fast: 1 month operating platform, 2-3 days implementation and it works!

Ingredients to our first (of many) use cases

Jibe platform API, internal SFTP for current subscribers list, content

Node.js SDK, several additional packages, all open-source

This use case is being elaborated and was a motivation for many of us to think beyond “the service”


TAKE-AWAYSTHE WEBIFICATION OF COMMUNICATION

If you do Joyn, have the right approach and get the right partner

Do not just blindly integrate to the IMS, do not only evaluate your AS for SIP ISC, but more importantly northbound integration capabilities using REST/JSON

Standardization aspect of add. capabilities irrelevant, simple REST API (maybe with SDK) more important

“Proprietary” per Telco definition ≠ Not usable by others (REST + doc/SDK completely fine for web developers)

Understand and acknowledge the tremendous change to our core business and its paradigms – “think web”

Standardized core technologies (HTML/CSS/JS, Objective-C, Java), but not services

Standardized interfaces (REST API w/ doc/SDK is enough) trumps complex E2E scenarios

Ownership of the screen has a huge impact of how service experience is created

It is imperative that any new service is considered both from technology and service evolution perspectives


SUMMARY

Honest thoughts that should have overall positive notion, despite certain critical annotations!

I am still not too optimistic for Joyn, but can see some potential for Joyn

I think your help is needed…

… also in your interest

Web technologies leave carrier approaches towards services behind

Fit-for-purpose applications create real value, every operator needs new revenues

Empty promises must not convince any longer, eventually they are going to be questioned!

Creating values beyond the service Joyn is something you want to do, too! Expose your platforms, incl. Joyn


service platform (get a good partner)

vendors, operators, GSMA, executives, colleagues

Less ubiquitous, but more targeted applications will replacegeneral purpose legacy-concept communications use case by use case!

THANK YOU.Sebastian Schumann

Application & Platform Innovation | Slovak Telekom, a.s.

[email protected]

@s_schumann

+421 903 419 345

ATTRIBUTION

Jibe Mobile, Inc. jibe is a registered trademark. The jibe mobile logo is owned by Jibe Mobile, Inc.

Joyn and the Joyn logo are a trademark of the GSMA.

Past designed by Megan Sheehan from the Noun Project

Forward designed by Austin Condiff from the Noun Project

Swiss Army Knife designed by Olivier Guin from the Noun Project

Knife designed by Gregory Sujkowskifrom the Noun Project

Knife designed by Gregory Sujkowski from the Noun Project

Knife designed by Antony Bayo from the Noun Project

Knife designed by Erik Wagner from the Noun Project

Scalpel designed by Danny Sturgess from the Noun Project

Tools designed by jessie_vp from the Noun Project

Saw designed by Arthur Shlain from the Noun Project

Drill designed by Alexandr Cherkinsky from the Noun Project

Flash designed byGeorg Habermann from the Noun Project

Life Saver designed by Percy Batalier from the Noun Project

The Twitter handle s_schumann is my personal one. On Twitter, you will discuss with me and face my opinions, not my employers!

19

http://www.thenounproject.com/megan.sheehan

http://www.thenounproject.com/

http://www.thenounproject.com/acondiff


http://www.thenounproject.com/olivierguin


http://www.thenounproject.com/GregSuj


http://www.thenounproject.com/GregSuj


http://www.thenounproject.com/Antocratie


http://www.thenounproject.com/ew1127


http://www.thenounproject.com/dannysturgess


http://www.thenounproject.com/jessie_vp


http://www.thenounproject.com/ArtZ91


http://www.thenounproject.com/alexandr.cherkinsky


http://www.thenounproject.com/georghabermann


http://www.thenounproject.com/pbatalier


Deployment Options With Hosted RCS

Technology

Transcript of Deployment Options With Hosted RCS