The Symbian OS (779886), страница 93
Текст из файла (страница 93)
File system extensionssupporting flash-file storage media have been added. Flash systems arenot byte-addressable, so conventional read–write mechanisms have to3It has close to 80% of the market, see Chapter 2.440SYSTEM EVOLUTION AND RENEWALbe completely redesigned. Flash systems also have a more limited lifetimethan other memory technologies, supporting a lower, fixed number ofaccesses before wearing out, which means that memory accesses mustbe evenly distributed across all sectors of the card and not concentratedin one physical location.
These all imply significant behavioral differences which must be abstracted by the file-system server to provide acommon file-system interface. (The behavioral differences between NORand NAND flash have also become significant as phone vendors haveadopted the cheaper NAND technology as a way of boosting internalmemory size in a cost-effective way.) Similarly, solutions such as demandpaging have been explored as solutions both to RAM inflation and tomobile disk-based storage options.Performance improvements have also been made throughout the system, at all levels from application support to the kernel and otherlow-level system areas. At the low level, file seek time and interprocess-communication timings have been improved, in addition tothe fundamental work of managing interrupt and other low-level processlatencies as part of the real-time reengineering of the kernel. In the application support layers, significant effort has been spent to maintain andimprove the core PIM application engines, to keep them up to speedwith current technologies as well as with evolving expectations.
ThusAgenda, Contacts and Messaging have all had their share of renewalthrough recent releases of the operating system, particularly to improveperformance.17.5Telephony EvolutionTelephony is an obvious area in which technology has evolved at arelentless pace since the first Symbian smartphones came to market. GSMhas been enhanced with successive generations of go-faster technologiessuch as EDGE and with half-way house technologies such as GPRSwhich extend the basic voice capabilities of GSM with packet-baseddata services.
Finally, it has evolved to full 3G, with packet-based voiceand data services. 3.5G network technologies are now reaching themarket and 4G will no doubt soon start to emerge (although it is not yetclear what 4G networks will mean). As well as this kind of generationalnetwork change, there is the further complication of a global marketdivided between competing network technologies, although GSM has,to date, dominated globally over the North American CDMA alternative.Unfortunately, 3G perpetuates the divisions. 3G evolution is based onstandards but while GSM evolves to the 3GPP standard, CDMA evolvesto CDMA2000 and remains as incompatible as its 2G counterpart.Further disruptive change is promised as competing high-speed wireless technologies such as Wi-Fi and WiMAX converge with the latestTELEPHONY EVOLUTION441telephony technologies.
It is not clear what mix of standards will succeedor which technologies will dominate. But clearly, to retain its currentadvantage, Symbian OS needs to be flexible, adaptable and to supportthis technology evolution seamlessly.To some extent, the beginnings of the telephony architecture evolutiongo back a long way, to Symbian OS v7 and even earlier.Andy Cloke:We have invested a lot of time and effort in multimoding the ETel API tosupport the North American market where the CDMA2000 specification, theQualcomm-influenced specification to put it like that, was prevalent.
Ouroriginal ETel API was very GSM-centric. Since 3GPP specs are based on GSM,that translates nicely across to 3G in Europe and Japan and anywhere elsewith a GSM footprint that is upgrading to 3G, but it doesn’t translate well tothe North American and Korean markets.
So that was the ambition, to supportboth GSM and CDMA, with a view toward 3GPP and CDMA2000.Since the lead time for getting these sorts of software components right isquite long, the work started off quite early. So we had to scour the QualcommCDMA specifications and work to align data formats, data structures, requests,responses and notifications, and sort out where we could align and where wehad to create two separate functions, one which would be used in GSM andone which would be used in CDMA2000. And, of course, the design principleis to support keeping the phone engine as simple as possible.
You don’t wantto say ‘Dial a Qualcomm voice call’ or ‘Dial a GSM voice call’; you just wantto say, ‘Dial a voice call and here’s the number I want you to dial’.The aim was not so much to support multimode phones capable ofboth GSM and CDMA operation, as to support phone vendors with portfolios of phones targeting all markets. For the vendor, being able to buildboth GSM and CDMA phones, or their 3G equivalents, from a singlesource base is a significant advantage (even though the source base ismore complex), allowing maximum reuse of software across a phoneportfolio.Andy Cloke:The core ETel stuff actually is very thin. So, for example, SMS transmissionand reception is an ETel extension. And it turns out that the multimode ETelextension is almost so standard that you’d always have to use it. But the pointis that it did give us another opportunity to redesign.
For example, when wecreated the original GSM API, we had a split between Basic and Advanced.The idea was that you would have the core ETel which would be suitable forstandard wireline modems, and the Basic ETel extensions would be suitablefor a phone connected by wire or infrared, a two-box solution, and Advanced442SYSTEM EVOLUTION AND RENEWALwould extend on top of that and would be suitable for a phone where thesignaling stack is built in.
That was the original design intent, but we neverreally ended up using just Basic ETel, so it was good to be able to deprecatethat.It may seem an obvious point, but in the early days of Symbian,phone expertise was hard to find. The company’s own background hadbeen strongly PDA-based, with a particular flair for squeezing powerfulUIs and applications into diminutive machines. Conventional networking technologies were well understood and fixed-line telephony wasa well-understood technology.
But mobile telephony was still highlyspecialized and mostly disjoint from more conventional computing.Embedded systems was a similarly highly specialized field. Few individuals (and companies) had expertise across all those boundaries.Andy Cloke:By the time we got to develop Multimode ETel, we were a lot more experiencedin the whole phone area.
By then, we had people who had come in fromcompanies where they had been developing GSM phones, so they thoroughlyunderstood all this stuff.Supporting all the available global telephony standards is a prerequisitefor a genuinely capable phone operating system. Because those standardscontinuously evolve, the operating-system support for them must continuously evolve. Without an extensible telephony architecture that kind ofevolution is impossibly hard.
The goal of an extensible architecture is notsimply to make evolution possible, it is also to make it as easy as possibleand as safe as possible since, in any system, change is expensive; in acomplex system, all change is also a risk to the stability of the system.Another rather more minor example of the way that the telephonyarchitecture has changed in unforeseeable ways is exemplified by theintroduction of the ETel third-party API in Symbian OS v6.1. In theoriginal release of Symbian OS v6.0, ETel was substantially open tothird-party developers. The release of Symbian OS v6.0 SDKs whichdocumented in detail the ETel APIs for the first time caused concern forsome licensees,4 reflecting extreme operator nervousness about possibleimplications for network security. It should be remembered that SymbianOS was not just the first, it was also the only open operating systembeing used as a platform for phones.
(And, arguably, it still is.) Operators4At that time I was managing the documentation team which had published thecontroversial APIs and I saw very clearly the upheavals it caused.SOUND AND VISION EVOLUTION443had simply never been in a position in which their networks were evenpotentially open to third-party developers.
A solution was rapidly agreed,the API documentation was withdrawn and an open subset API wasintroduced (and documented) to abstract public telephony behavior toenable applications to control phone calls, while the underlying API waslocked down for internal use only.5Again, future change is foreseeable in principle but never in detail.Extensible design is the only assurance against future disruption.17.6 Sound and Vision EvolutionAnother area of rapid recent technology evolution is multimedia, and thisis again an area in which Symbian OS has undergone significant architectural change.
Symbian OS has always supported sophisticated soundand image-based applications, with Symbian OS v6.1, for example, beingthe platform for the first Nokia camera-phone in Europe, the Nokia 7650.Multimedia really arrived for the first time in Symbian OS v7.0s whichintroduced a new multimedia server.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
