Thursday, 15 March 2012
Tuesday, 10 May 2011
The following is edited from the 3GPP documents:
IP is being introduced in both fixed and mobile networks as a more cost-effective alternative to circuit switched technology in the legacy PSTN/PLMN, as well as the underpinning transport for delivering IMS based multi-media services.
In order to ensure carrier grade end to end performance, appropriate interconnect solutions are required to support communications between users connected to different networks. There are currently a number of initiatives underway outside 3GPP addressing IP Interconnection of services scenarios and commercial models to achieve this; for example, the GSM Association has developed the IPX (IP Packet Exchange). Also, ETSI has recently defined requirements and use case scenarios for IP Interconnection of services. These initiatives require the use of appropriate technical solutions and corresponding technical standards, some of which are already available and others which will require development in 3GPP.
Moreover, new models of interconnection may emerge in the market where Network Operators expose network capabilities to 3rd party Application Providers including user plane connectivity for the media related to the service.
The main objective of IPXS is thus:
To specify the technical requirements for carrier grade inter-operator IP Interconnection of Services for the support of Multimedia services provided by IMS and for legacy voice PTSN/PLMN services transported over IP infrastructure (e.g. VoIP).
These technical requirements should cover the new interconnect models developed by GSMA (i.e. the IPX interconnect model) and take into account interconnect models between national operators (including transit functionality) and peering based business trunking.
Any new requirements identified should not overlap with requirements already defined by other bodies (e.g. GSMA, ETSI TISPAN). Specifically the work will cover:
• Service level aspects for direct IP inter-connection between Operators, service level aspects for national transit IP interconnect and service level aspects for next generation corporate network IP interconnect (peer-to-peer business trunking).
• Service layer aspects for interconnection of voice services (e.g. toll-free, premium rate and emergency calls).
• Service level aspects for IP Interconnection (service control and user plane aspects) between Operators and 3rd party Application Providers.
To ensure that requirements are identified for the Stage 2 & 3 work to identify relevant existing specifications, initiate enhancements and the development of the new specifications as necessary.
The following is a related presentation on Release-8 II-NNI with an introduction to Rel-9 and Rel-10 features.
The 3GPP references can be seen from the presentation above.
European Commission conducted a study on this topic back in 2008 and produced a lengthy report on this. Since the report is 187 pages long, you can also read the executive summary to learn about the direction in technical, economic and public policy.
Tuesday, 1 March 2011
I have heard quite a bit about Rich Communication Suite (RCS) recently. It was supposed to start become popular by 2011 but Infonetics puts it as a little too late to become mass market anytime soon in a recent report. The new report forecasts that there would be around 6.8 million RCS subscribers worldwide by end of 2012.
Dean Bubley from Disruptive Wireless released a report some months back saying that RCS is a bit too late and inflexible and the built-in assumptions have problems which wont make it a mass market technology.
Anyway, I decided to explore the technology a bit to understand it better. Before we start digging into this, the following Youtube Video gives a good overview of what RCS is supposed to be:
The following article gives a good summary of RCS as of now:
The GSMA is welcoming a new version of Rich Communication Suite (RCS) that will enable mobile phone customers to use instant messaging (IM), live video sharing and file transfer across any device on any network operator. Deutsche Telekom, Orange, Telecom Italia, Telefonica and Vodafone intend to commercially launch RCS across several European markets from late 2011, and additional operators are expected to launch later in 2012.
Once adopted, Rich Communication Suite – e* (RCS-e) will enable customers to use these enhanced communication services across mobile networks in a simpler and more intuitive way. It is based on a specification put forward by Bharti, Deutsche Telekom, Orange, Orascom Telecom, SK Telecom, Telecom Italia, Telefonica, Telenor and Vodafone which aims to lower the hurdle and speed up the market introduction and adoption of these services.
With RCS-e, customers will be able to use IM, share live video and share files such as photos simultaneously during calls, regardless of the network or device used. RCS-e will enable users to communicate in a very natural way, much like with GSM voice and text today, and will also offer the simplicity and security customers expect from mobile operator services.
As customers open their address book, they will be able to see which communication services are available to them. They can then choose their preferred communications option. For example, a customer would see if their contact is in an area with 3G coverage and is able to receive video.
The participating operators will work with handset suppliers to ensure the service is integrated into the address books of devices, so that customers will not have to download any additional software or technically configure their handsets in order to benefit from the enhanced experience.
“Mobile operators are committed to giving their customers greater choice in the way they communicate with one and other,” said Rob Conway, CEO and Member of the Board of the GSMA. “We welcome the pragmatic approach taken by these operators to accelerate the commercialisation of RCS and simplify the experience for mobile customers and we will work to adopt this specification within the RCS initiative.”
The RCS specification is designed to be interoperable between all operators and devices, giving customers greater choice in how they communicate. The new RCS-e is the result of extensive trials and is a subset of the current RCS 2.0 standard with enhancements. It is focused on extending the principles of voice and SMS calls to deliver an advanced set of interoperable data-centric communications services.
* RCS-e is a new enhanced version of the RCS specification which is based on the use across networks of IP Multimedia Subsystem (IMS) technology, an architectural framework for delivering Internet Protocol (IP) multimedia services.
The following presentation provides a bit more detail
Eduardo Martin's blog provides some more insight into the RCS Releases:
RCS has 3 releases, each upgrades the previous one. I will focus on SIP Presence only, but RCS touches more than SIP Presence, it also works other services such as IM.
RCS Release 1 evolves around the concept of the Enhanced Address Book (EAB), an evolution of the usual address book. In short the address book is decorated with enriched information, coming from different services. This plays nicely with today's wishes for cloud stored information, unified social networks status updates, contact content such as portrait icons. I'm not going into technical details, but I for sure am someone who is aware of the design issues around SIP Presence, its hard time scaling due to huge traffic, the dozens of ugly workarounds to make it work, and RCS is a nice step forward into the right direction, there are simple decisions that deeply simplify the network design, making it more like "old" presence networks, which simply work. One remark, it takes quite an effort to define this endorsing IMS and OMA, 27 pages of functional description, plus 39 of technical realization, it should be a lesson for everyone in these standard bodies when defining more extensions or new versions.
The RCS Release 2 effort focuses on enabling access to rich communication services from a wider range of devices. In short it tells that the user has multiple devices, for instance a mobile phone and a PC, possibly concurring for services, and adapts Release 1 for that. It also introduces the Network Address Book, which is just the realization that the EAB needs to be in the network and sync the multiple user devices.
The RCS Release 3 mostly consolidates Release 2 features, and adds some minor enhancements, such as preparing the network for different usages of it, for instance users with devices, which are not connected to mobile network, instead only have broadband connections. In my humble opinion a very important and positive decision, it's about time to consider these scenarios and find out new opportunities. It is weird to say this, but the fact that the industry finally acknowledges that content sharing between two users may happen off the voice/video session is a victory, welcome to the world not session centric.
The RCS specs are available here.
Friday, 3 December 2010
Very interesting presentation from NTT DoCoMo in the IMS workshop I blogged about yesterday. It shows their strategy to move from legacy core network to an All IP Network (AIPN).
Thursday, 2 December 2010
The 3GPP release 8 IMS Implementation, Deployment & Testing workshop took place in Sophia Antipolis on 24-25 November 2010.
The event was attended by 70 delegates actively participating to the discussions.
Presenting companies included: Tel : A1 Telekom Austria, Alcatel Lucent, Codenomicon, Conformiq, Eircom, Elvior, ETSI, France Telecom, GSMA, Huawei, Huawei, Mobitel, NTT DoCoMo, SFR, Telecom Italia, TestingTech, TU Berlin, Wind, Wipro, ZTE.
Here are the highlights from the ETSI document:
Goals and Outcome for this workshop
Share exprience from IMS implementation
Highlight areas for further specifications, for
Standards and Testing
Learn of issues and possible resolutions
Comments from The IMS Network Testing Group
Develop IMS core network test specifications based upon 3GPP, for:
• network integration
Hold interoperability events (IMS Plugtests)
Coordinate with other organisations such as OMA, MSF, GSMA
• Beyond small islands, second wave to replace unscalable, unmaintenable early VoIP systems
• Implementation options - Hybrid CS-GW for transition from CS to LTE, which already has 2 million subscribers on IMS/CS-GW/RNC
• Auto provisioning - to simplify complexity
• IMS functions must be implemented in the core – not in any access network, such as LTE, and can be used for non-Voice as well
Implementing RCS (Rich Communication Suite)
• RCS trial feedback - Good feedback from 400 trial users on RCS but difficult to configure SBC
• RCS implementations should include aggregation with SNS (Social Network Services)– eg contact list from Facebook
• Most appreciated feature of RCS is: - cross-operator interworking and compatibility with ordinary phones, not just smartphones
Specific Issues and Resolutions
• FAX – Delay and Jitter issues - FTTH will solve long delays etc
• Emergency and Lawful Intercept with IMS -There are standards and developed solutions available but Currently still falls back to CS /TDM
• Data Provisioning speed is important, to achieve no service interruption.
• 3GPP II-NNI: Inter-IMS Network to Network Interface - Two levels: Solx (service with control function) and Coix (connection – a pipe for media).
• “PathFinder” Global ENUM – like DNS for phone number; It is a solution to number portability and can optimise routing
• Most issues are Beyond IMS - integrating OSS/BSS, existing systems, inter-vendors interfaces
• IMS and IN - Pity the Standards did not bring IN and IMS close together; Need iFC enhancements, like in IN; Need to support combining services
• OTT and SNS dominate growth - occupies the minds of commercial people, GSMA-like services have slowed down
• Service layer (Wipro) – Telcos want one SDP to serve all - include IMS and non-IMS services, human and non-humans on NAB, context based, and charge only what is ‘consumed’
Testing Methods, Tools and Test Beds
• Integrate Conformance checking with interoperability testing
• Automation of interoperability trace checking – it can reduce costs by more than 50 % compared to manual validation
• Independent Test Bed- available EPC playground for prototyping applications
• Protocol message customisation tool - allows changing the message and customise the flow
• Security testing tool - testing by ‘fuzzing’, 100% TTCN free – everything is already build in
• IMS is a multi vendor environment - Testing and validation must be an integral part of the deployment process
“IMS is a Journey, not a destination” (ALU)
“SDP is almost anything” (Matjas Bericic, Mobitel)
“Voice as an app versus Voice as a Service” is a challenge (Manuel Vexler, Huawei)
“IMS is not a box, it is a network” (Matjas Bericic, Mobitel)
“global ENUM is DNS for phone numbers” (Adrian Dodd, GSMA)
“Kill with one SIP” (Ari Takanen, Codenomicon)
“ IOP is the red thread running through the entire ETSI standards development process “ (Milan Zoric, ETSI)
All documents from this workshop is available at: http://docbox.etsi.org/Workshop/2010/201011_IMSWORKSHOP/
Tuesday, 14 April 2009
Wednesday, 6 February 2008
An IMS service is a service that makes use of SIP and the IMS either centrally or marginally.
SIP itself and even more, the combination of SIP with other protocols can give birth to a flurry of new services, some of them implemented on IMS.
The ability of SIP to combine various existing services of different types (communication, data, content, applications) can give birth to a new user experience, which is by itself a new service. This is an important matter to consider when comparing SIP with more purpose-centric protocols.
These new services can reach a huge community covering all the continents, all types of access technologies and spreading between telco domains, other business domains, and the Internet, possibly redefining the definitions of these domains.
IMS and SOA (Service oriented Architecture) are not alternative architectures to deliver new services. They should rather be seen as building blocks permitting to create a new and more powerful service architecture called UOA (User Oriented Architecture).
This draws a potential future world, in which there might be a little bit of SIP everywhere, and consequently a a good potential for IMS to fit as a particular SIP service architecture deployed by telco operators.
However, history shows that the best technologies do not always prevail. In a possible future, the potential of SIP as a service control protocol used in different architectures including IMS, and/or IMS as a service architecture augmenting the intrinsic capabilities of SIP, might eventually fail. Conversely, would SIP and/or IMS be only used at a fraction of their potential (e.g. for VoIP and a limited set of additional services), they could still be a success.