Symbian OS Communications (779884), страница 82
Текст из файла (страница 82)
esk file (bt.bt.esk for Bluetooth,ir.irda.esk for IrDA) to set the ‘port= ’ field to an unused COMMport. Preventing the TSY from using the COMM port is often harder.Symbian has internal mechanisms for preventing the telephony subsystemfrom starting up, mainly by preventing ‘watcher.exe’ from loading, but theadditional dependencies introduced in the UI platform SDKs make thistask more difficult. Altering the PortName fields in the ModemBearerrecords in CommsDat can help, but this depends on how the TSY that isin use gets the information about which port to use.13.6SummaryIn this chapter we’ve:• covered how to set up the Symbian OS emulator for a variety ofcommunications development tasks• seen both the standard methods that can be used in most cases toconfigure the emulator, as well as a lot of advanced information aboutmanually tweaking configurations• discussed a few of the common problems that can occur with each ofthe setups, and some possible fixes for them.14The FutureAs you’ve probably noticed, the rate of change in the world of mobilecommunications is rapid.
Making predictions about the future can oftenend up making you look foolish later when something totally differenthappens; and making accurate predictions is hard, as many technologypundits have found out over the years. So we’re not going to claimthat our predictions are accurate or sensible! However, we’re still goingto rush headlong into picking some interesting future technologies thatmight turn up in Symbian OS, or problems that need solving in today’scommunications environments. We should say at this point that this is inno way an official list, and Symbian may not be working on technologiesin these areas – this is strictly a list drawn up by the authors of this bookbased on our own experiences.
(Just to make it clear who’s responsiblewhen it turns out we were completely wrong!)We’ve divided the list up into three main areas – networks, servicesand interaction. By networks, we mean the underlying networks thatactually move the data around. By services, we mean the applicationsyou can use over a network to accomplish something that you want todo.
By interaction, we mean better ways to actually make use of thenetworks to get to the services. In each case we’ll pick an example or twothat illustrates the work being done in these areas, or the problems thatremain to be solved.14.1 Better NetworksOne of the most obvious trends, which shows no signs of stopping, is thequest for more bandwidth. Each time a new technology is released – wiredor wireless – the next generation of services manage to step up theirbandwidth requirements to match. (Perhaps the other way to look at thisis that the previous generation of networks didn’t offer enough bandwidthto the services that used them!)408THE FUTUREOne topic closely related to bandwidth is the more general issue ofquality of service (QoS).
Of course, if you’ve got plenty of bandwidth thenyou’ve no need for any QoS mechanisms – if there’s never a decisionto be made between which of two (or more) packets to send next youhave neither the need for, nor the ability to apply, QoS. (Of course, youalso have the perfect network – so be prepared to make a lot of moneyfrom selling the technology!) This is QoS through overprovisioning, anddepending on which technology you’re deploying can either be extremelycost effective, or prohibitively expensive.In wireless technologies bandwidth is often at a premium, and wetherefore need to take a more sophisticated approach.
Offering reliableservices means deploying QoS solutions in our wireless technologies.These exist today for many technologies, so really what we’re expectingto see is their move to the mainstream as they become more and morenecessary to allow networks to differentiate between the ever-increasingamount of traffic flowing over them. And we’re not just talking aboutcellular networks here, but wireless LAN and Bluetooth as well, alongwith any future wireless technologies that come to market.Let’s have a quick look at one example which is currently offering thepotential for a significant increase in available bandwidth – the additionof a UWB bearer to the Bluetooth specifications.14.1.1 Bluetooth and UWBThe Bluetooth SIG have announced their intention use ultra-wideband(UWB) radios in a future version of the Bluetooth specification, alongsidethe traditional 2.4 GHz radios in use today.
This offers a potentiallymassive increase in bandwidth available to Bluetooth applications – somecurrent figures suggest at least 110 Mb/s, up from a mere 723 Kb/s in theoriginal Bluetooth specifications and up to 2.1 Mb/s today. This opensup several new use cases for Bluetooth devices that were previouslyproblematic, or impossible to achieve. New applications could includehigh-quality video streaming between your phone and your TV, muchreduced times for bulk data transfer to synchronize your music withyour handheld device, and allowing Bluetooth PAN profile to effectivelycompete with WLAN in data rate terms.The question mark remains over battery life though – is it possiblefor Bluetooth to maintain its reputation as a low power technologywhilst at the same time moving to a higher data rate? To some extent,such questions are irrelevant.
The old radio standard will remain indevices alongside the new one, allowing the selection of the appropriateradio based on the application’s requirements. In some ways this isthe ideal situation, even though it complicates the engineering of theBluetooth chipset, as it means that Bluetooth can address a wider rangeof applications, from low data-rate systems that need to minimize powerBETTER INTERACTION409consumption (such as HID devices – keyboards, mice and the like) tohigh bandwidth applications such as high resolution video streaming. Italso gives Bluetooth a clear advantage over wireless USB, which currentlyonly has the single, higher data-rate physical layer – without the fallbackoption that Bluetooth offers.14.2 Better InteractionWith ever-increasing numbers of wireless technologies, and an evengreater number of use cases, the problem of simple interaction with thedifferent technologies is becoming harder and harder.
Interacting withseveral of them at the same time is practically a nightmare! This is anarea where much work is going to have to be done to make the use ofthe technology as transparent as possible.There are two areas we want to focus on – interacting with a singletechnology in various use cases, and interacting with several technologies to achieve a single use case. Let’s look at the single technology,multiple use case scenario first, and compare and contrast some currenttechnologies – Bluetooth and TCP/IP.Bluetooth excels in the environment in which it operates – short-rangecommunication. It has excellent support for discovering devices andservices in the vicinity. That support has three essential parts: the abilityto present a list of devices in the vicinity, which is essential on deviceswith limited input capabilities as typing in names is much harder thanpicking from a list; the ability to query those devices to discover whatservices they offer; and the fact that the radio has limited range allowsa clear understanding of the distance of the discovered device fromyour current location.
And perhaps just as importantly, these services arestandardized for all Bluetooth devices.IP also excels in its natural environment. It can connect machines onopposite sides of the planet, scales to hundreds of millions of machinesbeing connected to the network, and can be made fault tolerant toallow parts of a network to fail and the whole system to keep running.Naturally, it does not offer the native ability to produce a list of allthe devices attached to the network – that too would be something of ausability nightmare!Now we have the problem of using either system outside the environment in which it was conceived – or, perhaps worse, combining thetwo systems together into one – which is exactly what Bluetooth PANprofile sets out to achieve. There is clearly some work to be done herein integrating the two technologies so that they fit together well (in factthe same point is true for using WLAN in an ad-hoc fashion on phonesand other non-PC devices).
No one wants to type awkward names, suchas ‘My Nokia N95’, or ‘SonyEricsson P990 into their phone to be able to410THE FUTUREconnect to a service offered by another local device – they don’t have todo this with traditional Bluetooth profiles, but anything offered over PANor WLAN can’t use a standard service discovery mechanism. (In fact,they can use any number of standardized service discovery mechanisms,just not a single standard one). There’s clearly room for improvementhere.Now let’s consider the one use case, multiple technologies scenario,but since there’s more of an answer there rather than a series of problems,we’ll pull it out into its own subsection.14.2.1 Automatic Bearer Selection and Bearer MobilityAs we’ve seen in this book, when you want an IP connection, the numberof possible technologies that can provide this on a mobile device issignificant, and increasing.