UNI versus propietary interfaces for communication services platforms

User-to-network interface or UNI is just a fancy term for naming the procedures and protocols that communication tools in the user hands (phones, mobiles, soft-phones, IM clients …) use to do their work and establish communicate with the network.
In the pre-Internet circuit based communication world, user devices were very simple, as simple and dumb as possible. Intelligence was supposed to be in the network. UNI capabilities were very limited, as corresponds to a very stable and limited service offer.
Internet turned upside down that approach: the “End to end principle” (https://www1.ietf.org/rfc/rfc1958.txt) translates roughly into “dumb network – smart endpoints”. It is assumed in the Internet that intelligence in the endpoints, and not in the network, that has a very important, but limited role: moving packets as efficiently as possible. Services are deployed in the endpoints, without relying on specific network behaviour. The UNI actually defines the services.
Telco core design (and a good chunk of the business) is based on the “smart network” view. The advent of IP based services thus supposed a revolution, and IMS was designed to mix both approaches: access and core assume the role of the “dumb network” efficiently moving IP packets, whereas the smart endpoints are the IMS, the application servers and the user mobile.
As in the Internet, in IMS the UNI comprises and defines the services. There is little difference between the UNI (client-IMS) and the ICS (app. Server-IMS) interfaces. One example is RCS: a rich, complete UNI that allows to perform all sort of service invocations and combine them with quite a lot of freedom.
Landing from these disquisitions to earthly matters: given that the UNI comprises the services, it is complete, stable, tested …. Wouldn’t make sense to extend the ideas explained above and use it also for communicating with the external, non-RCS world? We propose to use the RCS UNI to communicate web services, enterprise systems, and social networks with RCS.

Obviously the carrier is keeping a role, it's providing a valuable common enabler with its core, and assuring interoperability with other carriers & service roaming, security, and at the same time making easy for the ecosystem create mass market possible adoption for their solutions. WIN-WIN.
Why reinvent the wheel? Why spend money and time on designing new services interfaces when the UNI is there and contains the full service capabilities? Surely it is the better starting point.

Jose Recio

Key for success of RCS.

After "evangelizing" posts about RCS technology, own product portfolio explanation and demos, and finally, last week reflections on MWC RCS Seminar, we would like to add our view about key factors to make RCS a huge success and a new way of conceive mobility & unified communications.
The key advantadge of RCS is a type of "SMS enabler", only 1 experience to be learnt, very different use cases to be available using the service, all carriers, all devices compatible. This is the right way to address to the masses, not only geeks of smartphone owners.
On the other hand, unfortunately we are at the beginning of "all carriers, all devices, lots of services using RCS as door". Carriers start trialing RCS, and luckily with a good approach, including interoperability as part of trials (the 3 top carriers in France and Telefonica and Orange in Spain).

But...to run faster...there are a key few points:

a) Affordable core for small carriers, MVNO's and even servive providers trying to offer RCS using agnostic data connectivity. The good new here comes from Acme Packet, launching their new product Net-Net SIP Multimedia-Xpress

b) All devices. The good news come from Genaker with their J2ME RCS Client to enable the boost of RCS service usage before native clients arrive. (It won the RCS Innovation devChallenge).

c) Lots of services on top. The good news here come from us !!! The Solaiemes RCS Solution Gateway, is designed to create services on top of RCS being "content buddies" with no telco experience, the idea is merge internet & telco space, and our platform enablers the service creation based on APIs, being fully interoperated with telco IMS core to create fully compliant content buddies.

Then, even smaller innovative MVNOs looking to differentiate with compelling services, carriers looking for affordable service testing can save time to validate the service, and give a chance to the ecosystem to think about solutions, as it happened with SMS in the past...
And finally, let us remember how we finish our latest post, because it is the key to understand the battler, apps vs services...Devices apps could be the Ferraris, but the real success is the Ford-T, providing a nice experience everybody can afford in terms of cost & usability.

If you consider this post interesting to be shared, remember you can tweet this post using the button in the upper-left button :-)