Report on the ICIN 2004 Conference
From October 19-21, I attended ICIN 2004 in
What’s Hot? -- IMS, Web Services, and Parlay/X are
clearly the big topics this year. IMS is
seen as the next great hope for a converged services
architecture. (Comment -- I guess I’m a little skeptical having worked on converged
services architectures for 25 years and concluded there is no one right
architecture). Web Services is the
preferred protocol for everything.
Again, at this point I think the applications are not yet mature enough
to answer questions of performance, responsiveness, scalability, etc. which are
what come to mind when you look at the amount of software layering
involved. Parlay is much more popular
than I expected. Specifically
Parlay X (Web Services). There
seems to be at least some deployment of Parlay X and the beginnings of 3rd
party applications. Interestingly enough
deployment of IMS and Web Services is being driven much more in the fixed
networks than in the mobile networks where IMS was designed. The issue seems to be that
Convergence is also a major theme. Interestingly enough I think there is a split on what people mean:
I think this is an interesting observation. Several people also lamented that so far the major driver behind Packet technology in networks is that VoIP is being sold to the customer as a flat rate, cheap calling plan. Users don’t care about the technology, they do care about cost. Maybe Converged Services are something that users will care about, but I don’ t think that is clear.
Innovative services: Probably the most innovative things I saw were Amigo TV (Alcatel) which enables a group to watch TV while using chat and voice to communicate as if they were in the same room. It’s hard to judge whether this will actually be worth money to people. Second was the Virtual PBX (SpeakaNet). This is PBX services delivered to mobile phones. The service is slick and the economics are compelling. I frankly think this is a much better service than IP PBX. SPeakanet and others looking at it all seem to be doing it in a Parlay or Parlay X environment, which may well be a compelling reason to deploy Parlay.
General Mood: Cautious Optimism. Still a lot of churn and reorganization in the industry, but people are definitely seeing an upturn. Conference attendance is up, Services are being deployed. Companies like Marconi which were buried in Debt 2 years ago are now healthy again. Nobody is being lavish yet, but it’s a big improvement.
lots of discussion of where intelligence goes in next generation networks. Some in the terminal, but some things go in the network too:
Where is FT spending its efforts:
Some projects aimed at ease of use :
Roadmap on how to converge: Migrate real time services to common middleware, non-real time services to a unified service platform. Converge everything towards the IMS architecture.
Their current work on middleware is aimed at OSA/Parlay as the common set of APIs (no indication of which vendor or what services).
Handsets – they are working with manufacturers – they have a range of branded devices. They are working on both mobile and fixed endpoints. Key is to make sure they cooperate with the service platform.
About 220 attendees., up about 10%
from 2003. (Comment – at the program committee meeting we had a long discussion on
the state of the conference. By EU
standards this is a success (it’s been smaller and larger), and has a high
percentage of operator attendees. I talked with several friends here who also
attend VON and other shows in the
This talk was discussed by everyone as a big disappointment. Way too much of committees
and process, not much vision. As
an excuse he apparently very recently returned from a standards meeting in
Gave an example of the value of standards – US phones won’t work elsewhere, others will. (Way too simple of course). Another example – of the growth in the German economy over the past 30 years, 27% is due to standards, second only to capital as a source for growth.
Talked about how ITU-T has a reputation for being slow, but that’s out of date. With new Alternative Approval procedures, you can get approval in less than 2 months. This is responsible for 90%(?) of the current work. (Comment – He may have something. IETF scoffs at ITU, but if you look at the stagnation of SIP standards and others I am not surprised that ITU has improve by comparison.) The slide talked about reducing the time from 4 years +2-4 years for publication in 1988, to 2-9 months and 3-9 for publication in 2004
Talked about participation. US is still large,
but
Growing interest in standards in
He replaced the ETSI director scheduled to speak. Another disappointing (boring) standards talk. There was some speculation that part of the problem here was some kind of dispute between ETSI and ITU over not speaking in the same forum. No idea if this was a factor.
ETSI has 13,5000 publications, all
available free. The scope is fixed and
wireless, mostly telecom focussed, but wireless
covers data as well. ETSI also does compliance
testing. Their structure is based on
French law for non-profits (Based in Sofia Antipolis). They have about 100 staff members including 4
centers of core expertise, and pursue about 30 expert group projects
concurrently. Major emphasis in next
gene networks is focussed on TI-SPAN. This is the evolution of what was TIPHON and SPAN. (Comment – The Lucent
Geoff’s talk was a sales pitch for web services. The opportunity presented by web services is for Telecom operators to get into the value chain of enterprise to enterprise communication. That’s how you get
customer loyalty.
He described 3 waves of telecom services – POTS, where there were only a few hundred developers who could build services, AIN which opened to about a thousand, and NGN with 100,000+ (Way too low in my view).
He presented IBM’s service oriented architecture – basic approach is to design everything as re-usable assets. Standards are the key to doing this along with re-use. They reduce complexity.
Gartner view – Web services is the key source of communication between enterprises by 2007
He gave some info on their work with sprint. Sprint wanted to open their network capabilities to enterprise customers. The result was to embed sprint networking APIs in integrator applications.
Their SCE – Based on Eclipse plus a simulation environment (he felt simulation was essential because carriers don’t want to test in real networks), plus prebuilt service components. (Sounds very familiar). The prebuilt stuff is a framework plus lots of service components plus adaptors to integrate to network components. There was some discussion on how to find examples on the IBM web sites.
Questions – Dave Ludlam – where’s the boundary between standards and innovation. Geoff – 1st sprint projects were Microsoft maps presented to a pocket PC and a location based workforce management system. Part of their deal was that components introduced could be exclusive for 6 months but would eventually become standard. You need a policy of innovate, exploit, and then standardize.
Chet McQuade – Is there work on standardizing web human interfaces?
ETSI does this but as a separate user group. Big problem is getting input before there is
a final product. Project
I asked what ETSI and ITU were doing to bring in Cable. The answer was of course we do standards for them, but it didn’t address my real concern which was that the cable industry was unrepresented in the meeting. I had later discussion on this with others and I think among the technical people there is agreement with me – this conference, ITU, and ETSI are dominated by the Telco view. The view from Cable providers or ISPs may be quite different (and in fact it would be surprising if it weren’t)
He gave a rapid fire talk on services with lots of interesting observations. I’ve noted some of the better soundbites here, which 3 days later are still thought provoking:
Who is really leading telecom now? At first it was the engineers, then Marketing lead, now it’s finance. Are the lawyers next?
What do customers want? Mobile Broadband Internet – it’s that simple. Terminals are key and underestimated by carriers.
Keep things simple. Value isn’t in the bits it’s in the services (gave an example of SMS vs TV, 7 orders of magnitude difference in price per bit.)
“The future is fixed, with mobile access that makes it look mobile”. The point being that data networks and core services will be fixed, but access will be mobile.
Is UMTS the future?
Look at 802. It’s still not
obvious what the right answer is for data (and in fact it may vary depending on
where you are. In
“More bandwidth is fixed, more services are mobile therefore there is a need to converge.”
“R&D Turns Money into know how, Innovation turns know how into Money” – you need both.
Total market is huge, 1,200 Billion Euro in communication worldwide, 3,000 Billion if you throw in other digital information technologies.
SK Telecom is the largest Korean Telco. They are the biggest CDMA Carrier (18M subscribers, with 1XRTT deployed and EVDO deployed in 2002). He talked a bunch about broadband and the basic message was the motivation to buy is entertainment, and not all “family” entertainment. (The non-family entertainment accounts for something like 20-25% of the broadband revenue.)
He talked a lot about their wholesale call control offering, which is based on a Parlay architecture. It uses Marconi and Appium (Marconi infrastructure and Parlay gateway and an Appium layer on top. They also have billing and UDDI interfaces. One thing they had to do was put load control on top of it. They added a capability to initiate a call (basically make two outgoing call legs), and he went through a whole range of challenges including feature interactions, problems with caller ID, problems with carrier pre-select. They used it to do click to dial for home workers using a PC to initiate calls with their home phone. (Lots like converged desktop). Actually this talk was a bit disappointing because the focus was fairly narrow and sounded a lot like re-inventing things we already know how to do. The 21CN project is a much grander re-invention of BT as was clear from the talk given by BT later in the conference and the one given in the VASA workshop.
Those who know Roberto will not be surprised that he gave a very entertaining and provocative talk. He had a lot of material on convergence that he didn’t get to cover. Some notable sound bites though:
“The death of Network Intelligence” – Web Services Plus
Network Identity Plus Context = NetworkED
Intelligence. (i.e.
the future may not be in a centralized smart network but in a lot of
cooperating intelligent entities.) He
talked a bit about Skype, the peer to peer VoIP service. What
is happening is that Voice is going
Service metaphors – Talked about Remote controls and a virtual assistant as metaphors for services. Not sure what comes next (He had 2 more he couldn’t cover).
He is not a fan of SIP (Later he explained to me that he was being a little extreme to make a point). Real problem is one protocol isn’t enough. IMS with SIP control is way too complex (He put up a 3GPP chart) (Comment – these things are getting way too big and complex. Where did the Simple go?).
Solutions:
· OSA/Parlay “a la carte” – put in service discovery and a few services, not everything.
· SOAP, not SIP – SOAP is much more “IT Friendly” as a framework – not session oriented and no baggage.
· Intelligence will be everywhere – in the network in the terminal, and in 3rd parties.
He presented a system for rejecting SPAM (junk) calls over VOIP using essentially a private number (sub number) given to people you want to talk to. The caller then encrypts it using 1 way encryption and sends it to you along with the call attempt. The SPAM filter uses the info to screen for invalid caller ID before applying whitelist filtering. (Comment -- I can’t see how pure white list filtering is going to be useful to most people, since it is so severely restrictive in who it lets through.) (Global Comment – seems odd to have an operator spend so much effort figuring out how not to deliver calls).
Mona presented a scenario analysis of whether Secure Voice would be a killer App. I reviewed some earlier material for her. She had 5 scenarios including the current (nobody cares about security). In 2 others encrypted voice became a value added service, while in the remaining 2 it became either “table stakes”, or a service provided by smart endpoints which reduced carriers to bit pipes. Her conclusion was that secure voice was important enough to pursue (Her presentation was quite good, describing potential scenarios down to making up incidents and participants. I have no way to judge the accuracy of scenario planning as a prediction tool.
He presented some schemes for providing multiple levels of Qos for Voice. He proposed using DiffServ to establish protected bandwidth engineered to meet the load, multi-class queuing with packet dropping to handle overloads, and call admission control to regulate traffic. Some conclusions were that you could provide good QoS under overload at least to your top category, that admission control is necessary, and that dynamic algorithms for setting thresholds are better than static ones.
(One comment on this –
I worked with Bell Labs mathematicians on the mathematics for queuing in voice
networks 20 years ago and we were all surprised that Packet voice is worse
behaved statistically than Poisson – the standard distribution used for queuing
analysis. I don’t know what this guy
used, but what we found was that because packet sources are periodic and can be
“in phase”, you can have surprisingly large packet queues in the network even
at reasonable overall loads. )
(Another interesting
comment here – this is another case of someone spending a lot of effort to make
packet networks behave like circuit networks (i.e. behave like they had a fixed
group of trunks).)
This was a BIG session, well attended.
This talk was a little disappointing to me since I had talked to Bruno about this work a couple of times and had expected something more detailed and a more radical departure from SIP and IMS. Basically they presented the IMS model for invoking feature servers. Each user has triggers registered in the HSS that get loaded during a session and are criteria to divert the SIP invite to a feature server. After that the feature server can be a B2BUA, UA, Proxy, or Redirect server. The IETF has no discussion of how triggering is done. TISPAN is covering this for the 3GPP model with the implementation described here. It needs improvements:
· Failure based triggers (trigger on busy, no answer, network failure)
· Global Triggers (trigger on global numbers like 911 and 800)
There are issues in handling redirection. Sometimes the redirection is to another terminal for the same user in which trigger processing for the user should continue. Other times it’s “Call Forwarding” to a new user and triggering should now be restarted on the new user. IMS doesn’t support it now.
Trigger overriding is another potential area for addition. Application servers should only be able to modify certain fields in an Invite, except that “administrative application servers may override this (i.e. 911).
You also need a way of handling private fields in the messages that shouldn’t b given to the feature server but should be re-inserted in any sessions they proxy (e.g. private numbers, billing info, etc.)
IMS has a simple interaction check to try to determine whether services interact. It’s not sufficient because some services will always conflict in possibility. Checking has to be dynamic (an example he gave was prepaid and call routing in that call routing might incur more charges that prepaid hasn’t authorized). To solve this you need app server to app server communication, which can be done using the SIP body messages or through an external IP connection. (Not sure what’s better).
This talk presented converged services involving IMS and circuit switching. More specificly you want to allow things like a voice session in conjunction with another media (e.g. Video), where the voice starts out at least as circuit voice. These things need Simultaneous Voice/Data (Which can be done on GSM and UMTS, but many handsets won’t do it.)
Assuming that the voice goes over the air in circuit form (GSM) there are two options:
The second alternative is better for now because it does not involve any real change to the IMS or anything special, just an application coordinating the sessions.
What intelligence goes in the network for this: Addressing and Charging. These are not good to do in terminals because of trust and re-use.
3GPP is working on standards for this (May 2004) in 2 stages, first stage the independent sessions model, second stage with more advanced capabilities focused on one session.
Bill gave a great overview – motivation for convergence is
often bundling (he went through the various business models for “triple
play”. One big motivation I didn’t
realize is that many of the “separate business” requirements around enhanced
services have expired, allowing carriers to bundle basic and advanced
services. Lots of possible
interconnections (circuit and fixed to packet and mobile). Today, commonality is built around IN. Next it is useful to introduce Parlay and Web
services on top of this to basically allow enhanced services delivered in IN. (Comment – Lucent has a Parlay product,
otherwise I can’t imagine why Parlay is a benefit here if there is no
regulatory requirement for an open interface, since he wasn’t particularly
talking about 3rd party services.
Maybe he meant to be.)
He talked about an interesting service: presence enabled voicemail – greeting reflects your presence and may have other options for the user (deliver to my mobile phone).
He said Verizon has recently introduced an SCP based Portal (IOBI) where they do web services control telephony. (I don’t know about this, but someone else told me that Telcordia had come out with a new updated application server so maybe this is a Telcordia add on to their SCP. Of course another participant told me that Telcordia is in some state of uncertainty because of the intent to sell off the company and that is getting in the way of retaining key people)
The next stage is IMS, where the same server controls both. This is basically when you can start to do lots of business services. Parlay is useful here to attach to circuit networks for controlling multiple sessions.
This session had about 50 people, not bad but clearly of less interest than IMS. My notes are limited here as I was a speaker in this session.
My presentation was on delivering high value voice services
(Centrex, VPN, etc.) to a mobile endpoint through multiple access networks and
multiple terminals. It was really a
message that the
He basically talked about the Liberty Alliance authentication framework and mechanisms. Basically your endpoint can be enabled to authenticate once with a server and then supply tokens to other services needing to validate your identity, or it can be done with a proxy which intercepts server requests for authentication and supplies it. (Rather like password managers on browsers I presume). A problem is that the service can’t tell when you were authenticated or force re-authentication. For this a lower layer has been proposed based on GAA session keys – basically you authenticate with a server which supplies you and the “identity server” session keys used for secure communication. The identity server can then supply tokens either to your client or as a proxy to services.
He described various types of personalization and mechanisms for it and briefly a mechanism to support it. My notes were very sketch on this presentation
He initially presented two kinds of personalization
He talked about various approaches and ended with personalization by composition – put personalizations together to combine independent personalisations. Web services has a way to do this (BPL – I think this is Business Process Language), but it’s too complex and needs to be simplified
This one talked about a personal area network of devices that may act as a single endpoint for a user. Middleware mediates all this. There is some work on this under another project -- MANET, which focuses on ad hoc networks, but personal networks are different – one device is in charge, others are subservient, and all belong to one user. (This is a bit like designing peripheral busses)
Devices discover each other and negotiate roles to join networks. There are Hosts, Routers, and Peripherals. He discussed authentication and IP addressing. One issue is that IP may be too much for low power devices, and it’s not clear each device needs an IP address anyway.
The planned work of this group is to explore application migration to the correct device based on power and capability. They have looked at implementations around Phones and PCs. Microsoft is pushing a PC perspective, but the question is will people carry them. Phones may not have enough power for this.
I arrived late for this session due to a meeting of the program committee and heard part of Rebecca Copeland’s talk (Marconi). What I heard there and in talking to her during the networking time was similar to a previous talk on service architecture describing the goal of getting to a clean layered architecture but being forced to live with “lumps”. Her actual analogies were to Pasta (“We want to be building Lasagna (layers) but usually are starting from Spaghetti and wind up with Gnocchi (lumps)”) I think her slides would be very interesting to look at.
This is where the program committee put the service focused talks which seemed to present something new. There was some discussion on the appropriateness of the name. Perhaps it will say something about the attendees that while the program committee had given the larger room to this session I believe there were as many or more people in the parallel session on service architecture.
I arrived for the tail end of this talk. I believe it covered the game that was being demonstrated in the demonstration room (though I never had a chance to see it) which was billed as a massively parallel high action game. Some of the issues included scaling to large number of players and dealing with latencies – HTTP latencies over wireless networks are too long, you need TCP.
Why push to talk – “Walkie Talkie like service. Easy user interface – pick a user and talk or pick a group and talk.
(Snide comment here. Am I the only one who doesn’t understand why
this service is popular? Watching the
people with Nextel phones bleep at each other it strikes me as telephonic
hell. As someone who used walkie talkies and had a CB license and equipment in my car
for several years I still don’t get this service. Presence enabled establishment of sessions is
great, but the constant handshaking of push to talk and alert the other party
is really annoying. I guess I learned
long ago though that just because I don’t like it doesn’t mean the service
isn’t popular).
Some ideas were forming dynamic push to talk groups. PTT is evolving into a multi-media service. Presence is an important component. Push to talk can be a streaming service or essentially “Voice SMS”. Today you have 2 service models, Voice and Messaging centric. PTT is in the middle. PTT based on streaming is also essentially multimedia – you can invite someone into a conversation that is multi-media/group based.
“Push to Show” – be able to stream images or video with a PTT invitation.
Architecture – based on IMS. 3 layers of relationship with the terminal (SIP based) – IMS client to IMS, Service enabler to enabling services (Presence, group management)
Client to applications – this is what implements the multi-media conference call.
This was one of a handful of really innovative service papers I saw in the abstracts and the presentation lived up to it. Amigo TV is a system for watching video with your friends. You use a headset and a standard remote, plus a set top box. Each user has access to a buddy list for his social network that shows friends and what they are watching. Each user can pick an Avatar for the display and use the remote to display emotions. You can invite your friends to watch the same show, and form group watching experiences where each user’s avatar is presented over the video in a corner of the screen. Users can chat or use VoIP to talk about the show. It’s really there to showcase Alcatel’s broadband services platform.
This is still a concept demo, but it’s implemented and they are about to trial it to get user feedback.
One implementation issue presented was Presence – they evaluated SIMPLE and XMPP as possible presence structures and chose XMPP because it handled groups better. The downside is it requires a central server for IM and presence. They use SIP to handle the voice streams and a reflector for conferencing (i.e. each user’s voice stream is delivered to every other and mixed locally.
One interesting question was can you handle multiple people watching from one location. This wasn’t a design requirement but they can do it by doing multiple logins from one point.
This talk captured the concept I have been suggesting to several people – the ability to replace land line phones and PBX/Centrex equipment with a software system delivering calls to mobile phones, and more importantly the ability for the mobile carrier to become the primary provider of high value business services.
The basic concept here is a PBX without any terminal
equipment, including attendant functionality.
Calls are delivered to mobile handsets using mobile numbers for dialing
and access. Attendant functions are
handled via
A key factor driving this is a 7 hear replacement cycle for
PBX technology. When one gets replaced,
the key decision factor is cost. They
can lower cost by eliminating equipment and eliminating redundant land line
CPE. They say that it’s also a big win
for the carrier because in
The “Messaging” in this talk described a user service (e.g. SMS, email, etc.), not messaging used in the implementation. Why Messaging ? SMS is where the money is. Carriers need building blocks that extend messaging into other applications to create more moneymakers.
Why Parlay? Momentum, lots of APIs. Parlay 5.0 will include J2EE bindings. Specifically they looked at Parlay X. Feel it is more implementation specific than Parlay but still protocol and language independent (only dependence is on web services). Version 1.1 (current) has 8 modules, Version 2.0 will have a complete service framework. Instant Messaging and SMS are supported through the APIs, and he feels it is efficient (not sure what he meant by it).
They built a messaging gateway that exposes the Parlay X APIs. Internally it uses a messaging router which at the bottom delivers to several different forwarders, for MMS, SIP, or any other. They can basically decouple the adaptation from the specific external interface. Adaptation does things like converting between the parlay X messaging APIs and standard Email, SMS, MMS, SIMPLE, etc, and is independent of the actual protocol used to deliver.
He went through the architecture of their IMS. They implement all the key functions for IMS. They have a relationship with T-Mobile on this which I think means T-Mobile is deploying this.
Convergent Services doesn’t mean Circuit and Packet, it means multi-media (i.e. user doesn’t see packets and circuits, let’s stop talking about technology convergence and start talking about service convergence).
The paper was really an investigation of the performance of Web Services in building conferencing services. She investigated Web Services as a service delivery interface versus Parlay over Corba. Her service for investigation was a complex multi-party conference call. She didn’t use the Parlay X APIs but instead built web services based components that provided conferencing (Parlay X doesn’t currently support conference calls and working around it would have been awkward). She was looking at implementation difficulty and performance.
Interesting result – Web Services function calls are much heavier weight, but you make a lot fewer of them because the components are higher level. The result is a lower performance penalty than you may expect when you look at it from the perspective of what it takes to implement an application. Parlay is also very complex to program – you have to know a lot about the underlying components. Web Services is in principle simple. She compared program size and had very large differences, especially if the Web Services program used automatically generated programming stubs. (Comment – I don’t know whether she also looked at stubs for Corba. Corba is very tedious if you don’t have support for generating the function calls).
Overall her evaluation was based on total delay to set up a conference. About 20% longer with web services. (With the way this was evaluated it will always be longer since the Web Services components invoke the same underlying Parlay capabilities as the services built straight on Parlay). Time delay for any individual function varied to up to 6 times as long. She also looked at network overhead. The web services implementation sent 2-3 times as many bytes over the network (again for individual primitives it was up to 6 to 1, but you made a lot fewer web services calls.)
I asked about delay in response to a network event and overall capacity. She hadn’t looked at either.
(Comment here on web services for service creation. After several days of looking at these systems I conclude that mostly what people are doing with them is 3rd party initiated sessions (e.g. click to call or conference), not network driven services (e.g. 800 number routing). Performance is a much less critical concern here because of two issues. First the services are typically smaller and separable (i.e. a single service has fewer service invocations per second), and more important they don’t have timing requirements based on the network timing models (e.g. IN timers running on SCP responses)).
Web Services are a nice delivery framework, but remember that more bytes in the messages and text messages means more time and network bandwidth. He also pointed out another issue which may or may not be real – Because they are human readable, there is a more significant security risk. (Comment, I think this is a red herring – with protocol analyzers everything becomes human readable).
Another point he made was controversial – he claimed that Web Services isn’t well suited to asynchronous events. This generated considerable discussion both in the questions and in after session networking. The Web Services invocation/execution model is stateless, which makes handling asynchronous events hard, but individual services don’t have to be. I believe the real answer is that Web Services doesn’t offer any framework to support Asynchronous processing, but it doesn’t prevent it either. Of course building software that responds to asynchronous events is traditionally a hard problem and a source of errors so the lack of any support for the developer may be a real issue.
He talked about an example – WebCard, which was a prepaid service for dialup internet access. They used Web Services in conjunction with Parlay based call control to do it.
He cited some additions needed to Parlay X in order to really address the needs specific to Fixed Networks:
Dave Ludlam asked an interesting question – How does a Web Services implementation address the 90% of the code that traditionally goes to error handling? The answer that came here was that lots of this gets bundled into the WS components with fewer things exposed to the developer. In discussions with Dave later, I think this is a real concern. Much of the complexity in traditional telecom services is building in service specific behaviors for every conceivable combination of asynchronous things the user and the network may do. This often isn’t in the simple definition of a service (e.g. “click to call” doesn’t tell you what happens if the person invoking it doesn’t answer their phone and it goes to voicemail, whose caller ID gets displayed under lots of conditions around who the people are, etc.) The need for these things to be service specific means you can’t bury them in the components and forget them. Lack of service specific handling of “error legs” is a major source of user dissatisfaction with internet and IT services).
This talk was really about moving sessions between multiple networks. The service example he used was a video stream that could be moved from a TV to a PDA to a PC and connected via cable, Wireles LAN, and GPRS.
He talked about terminal mobility (how to let the terminal move between access networks). 3 approaches:
What he was really looking at was Service mobility – Services that continue as the user moves across terminals. Here there were two approaches:
He described the video streaming example and demonstrated that they could move the session, and that most of the delay (a few seconds) was buffering and device turn on delay and not service mobility.
This was technically interesting, but I wonder what the real demand for migrating sessions between terminals actually is.
This talk was about selecting the best way to deliver MMS to a mobile terminal – Basic message was that if you could connect either via WiFi or GPRS, you may want to manage when you deliver messages to make use of WiFi when possible. If the current radio environment doesn’t support high bandwidth and you have a large message to deliver or upload you may want to wait until the terminal moves in range of a faster radio network. This also has power benefits since it takes less power to use WiFi for a few seconds than it does to use GPRS for a few minutes.
The talk described an architecture which allowed a
The basic idea here was to use a non-networked Bluetooth transceiver deployed in a location to allow terminals to detect their location and then deliver services specific to that location. The Mac address of the transceiver becomes a Tag that the terminal transmits to a database which then establishes the location of the terminal. To minimize power, the Transciever operates as a Bluetooth master and the terminal as a slave. To emphasize, Bluetooth is used only to exchange the “tag” to establish location.
They trialed this in the
A couple of key questions were – Why not just deliver services over Bluetooth (well that way the operator doesn’t get involved at all. The intended use was delivering “helpful messages” in malls and near stores)
Second, would RFID or some other technology work as well (They considered this but didn’t really explore it).
Kris’s talk was basically a sales pitch for Appium’s product, an application platform that sits on Parlay and exposes Web Services APIs both internally and externally. It was disappointing to get a sales pitch, but Appium was a key sponsor for the conference.
Why are open systems important -> Operators can’t address niche markets effectively because they are small compared to the operator’s business, but they are big for a 3rd party specialist. They are increasingly important.
Also Operators don’t own content, so they need open interfaces to support partnerships with those who can supply it.
Is OSA/Parlay enough?
Parlay X – Make it simple enough for 15 year old kids to build services. (Comment – not sure what this says about the error leg and operations) The intent here is simple services, not complex applications like a call center (Comment – supports my view that the focus of the web services service creation isn’t traditional services triggered from the network).
To accomplish this the platform has to provide 3 layers:
He described a solution for a global operator. (I think this is
Appium can run applications in the
server (Carrier applications) and can support 2.5K Web services transactions
per second. (Comment – sure, but doing what?)
John presented a summary of the VASA Forum’s two recent RFI’s on broadband services. These were on services in general and one
specifically on broadband enhancing traditional voice services. The VASA report will be published
separately. (Comment – I was one of the authors on the full report which will be
published later)
He talked a lot about service broker as a network function. A Service broker is a trusted intermediary between users and services. Has to keep users happy by managing privacy and providing ease of use and keep users happy by managing payments, common profiles, etc. The Parlay model doesn’t support all of it, so you need some other pieces:
His fundamental message was quite simple: To succeed you have to exceed customer’s expectations, not what they describe as their needs or desires. This is what he described as “expectation shock”. He gave a lot of examples of this. They did a lot of surveys on various services, discovering what was important, how the user expected the service to perform, and how they rated it. Reliability, Security, and speed were areas which in many services were very important but with low expectations.
One notable quote: “IT is like Telco was 60 years ago – not used to dealing with customers, customers have awful expectations” – Dave Ludlam
Tipping – you tip in proportion to how much the experience exceeds your expectation.
SMS – had low expectations and delivered something useful, users loved it.
WAP – hyped, high expectations, failed.
(Comment – Maybe there
is something here about airlines – Discount airlines are in fact worse than
major carriers, but your expectations are so low people like them, while
United, American, Delta, et al can’t get away with poor service because your
expectations are high).
(Comment – so we will
all succeed if we figure out how to lower customer expectations?)