Symbian OS Communications (779884), страница 35
Текст из файла (страница 35)
As with most network technologies that carry IP, there aresome configuration steps that are specific to GPRS, so we’ll explain thekey parameters that need to be configured. GPRS networks also offersome features which differ from other technologies, such as secondarycontexts – which provide quality of service (QoS) for traffic at the linklayer – we’ll discuss these as well.One thing worth noting is that when we talk about GPRS in thischapter, we mean GPRS services over both the GERAN (also known as a2.5G network) and UTRAN (also known as a 3G network).Let’s look at how a GPRS connection is created to see the different partsof the system and where the configuration parameters come from.
We’llignore some of the really low level details, like the physical channel overwhich these commands are transported, and the parts of the network thatare transparent as far as we’re concerned (like the actual base station thatreceives the radio signals), and just look at the higher level connectionprocess.The two key items in Figure 6.1 are the serving GPRS support node(SGSN) and the general GPRS support node (GGSN). The GGSN isthe really interesting node from the developer point of view, as this isconnected to the network we wish to access – typically either an operatornetwork, or the Internet.The first item of configuration information we need is the access pointname (APN), which is passed to the SGSN by the mobile handset.
Thisis then used by the SGSN to discover which GGSN we wish to connectto. Different GGSNs are connected to different external networks, so, forexample, one GGSN may provide access to the Internet, another mayprovide access to the operator’s walled garden network.SGSNGGSNIP networkFigure 6.1 Component parts of a GPRS connectionIP NETWORKS OVERVIEW157The other commonly required items of configuration information is ausername and password, although these are usually set to well knownvalues used by all users of a particular service.There are various sites on the Internet that list the APNs, usernamesand passwords for popular mobile operators; or settings can be sentover-the-air in a specially formatted SMS containing configuration information – these can typically be requested using the appropriate operator’swebsite.
Some recent devices also have a very useful function where theyidentify the operator from your SIM card and populate the access pointsettings from a local database containing access point information formany network operators.The configuration information is used to activate a network connectionknown as a PDP context, or often just as a ‘context’. This is a connectionfrom the handset to the GGSN, and provides access to the networkattached to the GGSN.Why so many APNs?A common question is why, when all the PDP contexts we are usingsupport IP, do we need more than one access point? Surely all trafficcould be sent over the same IP link to a variety of different destinations?The common reason for using multiple APNs (and therefore multiplePDP contexts) is for billing purposes.
It turns out to be a lot easier tobuild a network if you can just record the amount of data transferredthrough one of the GPRS support nodes (S/GGSN) rather than havingto examine every IP packet and determine which type of service (eg.internet, MMS, operator walled garden network) it relates to, and thenrun multiple counters for the different service types1 .
Similarly, it is easierto grant some users, perhaps depending the network tariff to which theyare subscribed, access to a greater or lesser set of services by allowing orblocking their use of certain APNs; for example, in the UK some networkoperators do not provide general Internet access to prepay customers.Most networks support between one and three access points, althoughobviously this is highly variable.Symbian OS, when using a cellular modem with appropriate capabilities, can support multiple contexts to multiple different APNs – althoughoften the number is limited because either the cellular modem or thenetwork have a per device limit on the number of contexts they can orwill support. There is also a maximum number of supported contextsdefined in the 3GPP specification, although we have yet to observe acase where this is the limiting factor.1Given the increased amount of processing power available today this is more feasiblethan it once was, but still adds extra overhead to the per-packet processing.158IP AND RELATED TECHNOLOGIESQuality of service on GPRS networksA feature that is unique to GPRS in implementation, if not in concept, isthe secondary context.
Unlike the PDP contexts we referred to before,which would more accurately be referred to as primary contexts, asecondary context carries some subset of traffic on the IP link. It is usedto provide differing quality of service (QoS) to different connections,typically different TCP or UDP connections.
Thus a device would havea single primary context and zero or more secondary contexts active, allusing the same IP address and connected to the same GGSN. Each of thesecondary contexts would typically have a non-default QoS setting – forexample, it might provide a lower latency and lower jitter service for realtime voice services, or a high bandwidth connection for video streamingfrom a server.Whilst packets leaving the local device can easily be transmitted onthe appropriate primary or secondary context, it is necessary to provideadditional information to the GGSN to allow it to map data coming fromthe external network onto the correct context. This is achieved throughthe use of a traffic flow template (TFT).
This is simply a data structure thatallows the local device to specify certain characteristics that can be usedto assign packets arriving at the GGSN from the external network to thecorrect context. TFTs can provide a range of parameters to classify traffic,for example TCP or UDP port number, or IPSec SPI.When using the RSubConnection API in Symbian OS, covered insection 6.6, the creation and handling of TFTs is taken care of by theGPRS QoS implementation so the application need only specify its QoSrequirements through the API.In addition to QoS on secondary contexts, it is also possible forprimary contexts to have specialised QoS parameters.
Whilst not used forthe majority of applications and access points, this feature is sometimesused to provide QoS-enabled links on networks where secondary contextsare not supported.Limitations on GPRS networksAs discussed earlier in this chapter, some networks have a limitation onthe number of active PDP contexts they support. The maximum numbervaries between networks, and even on a single network it changesoccasionally as network operators decide to increase the number ofactive contexts allowed.
It is possible, however, to see context activationfail because there are too many contexts already active. In this case it isoften best to indicate the reason for failure to the user (in less technicalterms, obviously) and let them solve the problem, as any attempt toshutdown other connections can be equally disruptive to the user ashaving an application fail to create a connection. Both S60 and UIQhave connection manager applications that allow users to monitor andIP NETWORKS OVERVIEW159close active connections – however, many users are unlikely to be ableto make a sensible decision about which connection to close, so thisfeature is only really useful to the more technical users.6.1.2 An Overview of MultihomingFollowing on logically from what we’ve just seen about GPRS with different services being offered over different APNs, it is obvious that ifwe want to support multiple services spanning multiple APNs that weneed the ability to use several network connections at the same time.Of course the connection lifetimes don’t need to be the same – networkconnections can start and stop independently, but it should be possible tocreate a new network connection even if there is an existing connectionFigure 6.2 shows a typical scenario.One common problem when using multiple connections, which isoften seen on PCs, is the routing ambiguity it creates.
In other words,it is not obvious which packets should be sent through which interface,or which interface’s IP address should be used as the source addressfor new connections. The simple solution to this is to designate oneinterface as the default – however, if different services are available overthe different interfaces (eg. MMS services are typically only available overa connection to the network operator’s MMS network) then the problembecomes much harder to solve. In some cases, when using the traditionalapproach of a single routing table to decide which interface to send trafficover, services may just stop working if their traffic is sent over the wronginterface. What is more, it often takes someone very familiar with IPnetworking to sort the problem out – and this isn’t something you expectfrom the vast majority of phone users.In cases where a device is connected to multiple networks that areadministered by different organisations the problem can get even worse.Many networks use ‘private’ IP addresses, as defined in RFC1918.