OSA defines an architecture to enable operators and third-party developers (e.g.,
value-added service providers (VASPs)) to make use of network functionality
through an open standardized interface (called an application programming interface
[API]). It provides applications with access to service capability servers, and
thus provides the “glue” between the applications and the service capabilities of the
network.
In this way, applications become independent of the network. But within the
network, features such as Intelligent Networks and CAMEL provide support for the
required services. The actual applications, however, can be executed in application
servers physically separated from the core network entities. They may be part of the
operator domain, or may be third-party applications. The OSA API is secure and
independent of vendor-specific solutions and programming languages, operating
systems, etc.
Wednesday, July 4, 2007
Software and Service Platform Requirements
There is a whole range of service platforms required in modern networks. They
include platforms for value-added services (VAS), such as voicemail, Short Message
Service SMS), and Multimedia Message Service (MMS). They also include
mobility databases, including home and visitor location registers (both of which
play an important role in service provision for GSM, GPRS, and UMTS); generic
service platforms, such as service control points (used in Intelligent Networks) and
service nodes. Finally, they include content servers, which provide access to basic
and advanced information, graphics, pictures, music, and video.
With the reduction in the cost of a voice call, the service platforms are assuming
greater significance as a way of providing value-added services in an attempt to
maintain and increase the average revenue per user (ARPU). In networks that are
optimized for data, such as ADSL, GPRS, and UMTS/3G, they provide the main
mechanism to grow the number of subscribers and to increase revenue.
The user would either be using these advanced data networks as a bearer to
access content and services from an independent provider, or be directed by network
resources (network-provided service platforms) to a point in the network where the
service can be accessed (network-provided service platforms or third-party service
provider platforms).
Network operators would like their customers to access the operator-provided
content and services so that they can capture the ensuing revenue, but increasingly,
third-party service providers are seen as an integral part of the overall system. In
fact, work has been done within industry and standards bodies to provide standard
ways of connecting third-party providers to the network so they can be accessed by
customers. Examples of third-party content and services include information such
as movie schedules, restaurant opening times and locations, credit card payment for
calls, navigation system updates (traffic updates), etc.
Vendors
Provision of service platforms of whatever sort is considered big business. For some
vendors, it is seen as a secondary function, helping to make the core product (often
telephone exchanges and routers) more attractive in that an integrated solution
can be provided, with the subsequent reduction in administration, testing, and
required employee knowledge base. Some vendors are seen as specialists in the area,
relying on reputation, and above all on an excellent product (or product range).
Example equipment vendors include, but are not limited to:
Alcatel
Ericsson
LogicaCMG
Lucent
Nokia
Nortel
Telcordia
Capacity
Capacity issues for service platforms can be quite complex, with huge variations
in usage throughout the day (which can be expected and predicted), and in addition,
variations occurring as a result of specific applications. These variations in
demand could be triggered by advertising campaigns for certain content, televoting
(by standard circuit-switched call, or messaging, for example), or perhaps by world
events dictating mass network usage (New Year’s celebrations, as an example).
In all cases, the service must be effectively managed. This includes the service and
application handling itself, as well as any congestion condition. Any request for service
that is not satisfied directly results in lost revenue. In addition, if congestion is encountered,
and appropriate announcements or responses are not given to the customer,
they will be dissatisfied and reluctant to try later, again resulting in lost revenue.
One of the main requirements therefore is to balance the cost of equipment
against potential usage, taking into account lost revenue through congestion.
This is easier to achieve for some platforms than for others. For example, platforms
that primarily provide database applications (such as a home location register
in GSM) can be planned, with forecasts of subscriber growth allowing a steady
scale-up of network resources. A known history of usage patterns for the HLR on a
daily and seasonal basis can be catered for.
Other platforms are not so easy to plan. These are generally the service platforms
that support a range of services (or a single service) that are influenced by less
predictable variables. For example, a service control point (explained later) handling
a televoting service will hit congestion levels early (and remain there) if a vote that
had forecast to receive two million votes actually receives three million. Although
mechanisms do exist within the technology to handle the congestion, the lost revenue
is still a huge problem. In any case, scalability is a big factor in service platform
provision.
Upgrading the network must also be transparent to the customer, leading to
the requirement for a flexible architecture. This would allow one to view a single
functional entity in terms of access to the service, but with the functionality actually
provided by a number of physical entities (servers), as shown in Figure 3.31.
This gives the required flexibility and scalability, allowing the network to grow at a
planned rate, while ensuring that spare capacity is calculated to cater for peaks, but
not be so great that it is wasted investment.
Redundancy
Some services and applications may be more critical than others. The high revenue
services should be protected from congestion when a mass service scenario is
expected. In addition, services and applications can be very different, with widely
varying requirements.
For both of these reasons, it is usual for a network operator to implement a number
of different service and content platforms. Even when the platform is generic
(such as an Intelligent Network service control point), it would generally be the case
that different platforms would support different services. There may be a platform
for prepaid billing, one for dialed network services, one for fraud control, one for
mass calling type services, etc.
In reality, all of these chosen examples could be provided by a single platform but
common sense dictates otherwise. Having a single platform implemented for each
service would not be ideal either. First, capacity requirements may require more than
one platform, but the other compelling reason is that of resilience and redundancy.
Continued availability of any service, even under platform failure, is extremely
important; hence, it makes sense for a service to be available for use by the required
customers in at least two platforms. The platforms would ideally be sited in different
geographical locations
include platforms for value-added services (VAS), such as voicemail, Short Message
Service SMS), and Multimedia Message Service (MMS). They also include
mobility databases, including home and visitor location registers (both of which
play an important role in service provision for GSM, GPRS, and UMTS); generic
service platforms, such as service control points (used in Intelligent Networks) and
service nodes. Finally, they include content servers, which provide access to basic
and advanced information, graphics, pictures, music, and video.
With the reduction in the cost of a voice call, the service platforms are assuming
greater significance as a way of providing value-added services in an attempt to
maintain and increase the average revenue per user (ARPU). In networks that are
optimized for data, such as ADSL, GPRS, and UMTS/3G, they provide the main
mechanism to grow the number of subscribers and to increase revenue.
The user would either be using these advanced data networks as a bearer to
access content and services from an independent provider, or be directed by network
resources (network-provided service platforms) to a point in the network where the
service can be accessed (network-provided service platforms or third-party service
provider platforms).
Network operators would like their customers to access the operator-provided
content and services so that they can capture the ensuing revenue, but increasingly,
third-party service providers are seen as an integral part of the overall system. In
fact, work has been done within industry and standards bodies to provide standard
ways of connecting third-party providers to the network so they can be accessed by
customers. Examples of third-party content and services include information such
as movie schedules, restaurant opening times and locations, credit card payment for
calls, navigation system updates (traffic updates), etc.
Vendors
Provision of service platforms of whatever sort is considered big business. For some
vendors, it is seen as a secondary function, helping to make the core product (often
telephone exchanges and routers) more attractive in that an integrated solution
can be provided, with the subsequent reduction in administration, testing, and
required employee knowledge base. Some vendors are seen as specialists in the area,
relying on reputation, and above all on an excellent product (or product range).
Example equipment vendors include, but are not limited to:
Alcatel
Ericsson
LogicaCMG
Lucent
Nokia
Nortel
Telcordia
Capacity
Capacity issues for service platforms can be quite complex, with huge variations
in usage throughout the day (which can be expected and predicted), and in addition,
variations occurring as a result of specific applications. These variations in
demand could be triggered by advertising campaigns for certain content, televoting
(by standard circuit-switched call, or messaging, for example), or perhaps by world
events dictating mass network usage (New Year’s celebrations, as an example).
In all cases, the service must be effectively managed. This includes the service and
application handling itself, as well as any congestion condition. Any request for service
that is not satisfied directly results in lost revenue. In addition, if congestion is encountered,
and appropriate announcements or responses are not given to the customer,
they will be dissatisfied and reluctant to try later, again resulting in lost revenue.
One of the main requirements therefore is to balance the cost of equipment
against potential usage, taking into account lost revenue through congestion.
This is easier to achieve for some platforms than for others. For example, platforms
that primarily provide database applications (such as a home location register
in GSM) can be planned, with forecasts of subscriber growth allowing a steady
scale-up of network resources. A known history of usage patterns for the HLR on a
daily and seasonal basis can be catered for.
Other platforms are not so easy to plan. These are generally the service platforms
that support a range of services (or a single service) that are influenced by less
predictable variables. For example, a service control point (explained later) handling
a televoting service will hit congestion levels early (and remain there) if a vote that
had forecast to receive two million votes actually receives three million. Although
mechanisms do exist within the technology to handle the congestion, the lost revenue
is still a huge problem. In any case, scalability is a big factor in service platform
provision.
Upgrading the network must also be transparent to the customer, leading to
the requirement for a flexible architecture. This would allow one to view a single
functional entity in terms of access to the service, but with the functionality actually
provided by a number of physical entities (servers), as shown in Figure 3.31.
This gives the required flexibility and scalability, allowing the network to grow at a
planned rate, while ensuring that spare capacity is calculated to cater for peaks, but
not be so great that it is wasted investment.
Redundancy
Some services and applications may be more critical than others. The high revenue
services should be protected from congestion when a mass service scenario is
expected. In addition, services and applications can be very different, with widely
varying requirements.
For both of these reasons, it is usual for a network operator to implement a number
of different service and content platforms. Even when the platform is generic
(such as an Intelligent Network service control point), it would generally be the case
that different platforms would support different services. There may be a platform
for prepaid billing, one for dialed network services, one for fraud control, one for
mass calling type services, etc.
In reality, all of these chosen examples could be provided by a single platform but
common sense dictates otherwise. Having a single platform implemented for each
service would not be ideal either. First, capacity requirements may require more than
one platform, but the other compelling reason is that of resilience and redundancy.
Continued availability of any service, even under platform failure, is extremely
important; hence, it makes sense for a service to be available for use by the required
customers in at least two platforms. The platforms would ideally be sited in different
geographical locations
Radio Resources
Radio Resource Procedures for GSM, GPRS, and EDGE
The general purpose of radio resource procedures is to establish, maintain, and
release radio connections. To be effective, the radio resource procedures are complex
and include the cell selection/reselection and handover procedures.
Radio Resource in Idle Mode
The mobile handset continuously monitors the system information broadcasts on
the broadcast channel, interpreting the information appropriately. This information
contains parameters such as the identity of the serving cell and information on
how to access the network.
Once the cell is selected, the mobile leaves the idle state to register its location with
the network. In the absence of any other activity, it then falls back to the idle mode, to
monitor the paging channel (to identify any incoming calls), updating its location as
required (periodically, or as location area or routing area boundaries are crossed).
Radio resource in idle mode:
Monitor system information broadcast (contains required information)
Cell selection
Cell reselection
Location registration and updating
Monitor paging channel
Radio Resource Connection Establishment
This is instigated from idle mode. The RRC connection request is sent from the
mobile to the network. This may be to make a call, transfer data, or update a location
or routing area. Once the connection is established, a confirmation is sent to
the mobile.
The mobile now moves into the connected state, sending a Radio Resource
Connection Setup Complete indication to the network on the dedicated channel that
has just been assigned.
Paging
For idle mode mobiles, paging is initiated over the required location area, or routing
area for incoming calls, or for session setup in the case of packet services. The
core network node (MSC / VLR or SGSN) initiates the paging procedure.
The paging message is broadcast using Radio Resource procedures on the paging
channel that each idle mode mobile monitors within the cell(s).
Other Radio Resource Procedures
Radio resource procedures are extremely comprehensive and cover a wide range of
requirements. Some of the procedures not dealt with here include:
Power control (uplink and downlink)
Handovers (can be extremely complex in UMTS/W-CDMA)
Connection release
Packet mode procedures
Radio Resource Procedures for UMTS (including HSDPA)
UMTS (Universal Mobile Telecommunication System) procedures follow the
general requirements for GSM and GPRS, except that the radio interface and
channel structure are more complex and therefore require more (and more complex)
procedures. This is also true for HSDPA (High-Speed Downlink Packet
Access), which is a specific implementation of W-CDMA used on the UMTS
radio interface.
The mobility management (MM) and connection management (CM) procedures
are essentially very similar to those discussed above, except that more options
are generally available with UMTS because of the multimedia-capable nature of
the connections. In fact, the procedures for the GSM family of technologies are
contained within a common set of documents (available through the Third Generation
Partnership Project [3GPP] Web site at www.3GPP.org).
The documents are arranged such that all procedures relating to MM and CM
will be in a single document, irrespective of access technology.
Radio resource (RR) management is where the main differences occur between
the technologies and, in this case, the procedures for UMTS (W-CDMA) are separated
from those for GSM, GPRS, and EDGE by the use of different documents
detailing the RR procedures.
First, the radio elements are known as the Node B, which is equivalent to
the BTS in GSM, GPRS, and EDGE, and the radio network controller (RNC),
which is equivalent to the BSC. The term “radio network subsystem” (RNS)
is used in place of the base station subsystem (BSS) used in GSM, GPRS, and
EDGE.
To illustrate just two of the major differences between UMTS (W-CDMA)
and GSM, GPRS, and EDGE, two procedures relating to radio resources (RR) are
described below.
The general purpose of radio resource procedures is to establish, maintain, and
release radio connections. To be effective, the radio resource procedures are complex
and include the cell selection/reselection and handover procedures.
Radio Resource in Idle Mode
The mobile handset continuously monitors the system information broadcasts on
the broadcast channel, interpreting the information appropriately. This information
contains parameters such as the identity of the serving cell and information on
how to access the network.
Once the cell is selected, the mobile leaves the idle state to register its location with
the network. In the absence of any other activity, it then falls back to the idle mode, to
monitor the paging channel (to identify any incoming calls), updating its location as
required (periodically, or as location area or routing area boundaries are crossed).
Radio resource in idle mode:
Monitor system information broadcast (contains required information)
Cell selection
Cell reselection
Location registration and updating
Monitor paging channel
Radio Resource Connection Establishment
This is instigated from idle mode. The RRC connection request is sent from the
mobile to the network. This may be to make a call, transfer data, or update a location
or routing area. Once the connection is established, a confirmation is sent to
the mobile.
The mobile now moves into the connected state, sending a Radio Resource
Connection Setup Complete indication to the network on the dedicated channel that
has just been assigned.
Paging
For idle mode mobiles, paging is initiated over the required location area, or routing
area for incoming calls, or for session setup in the case of packet services. The
core network node (MSC / VLR or SGSN) initiates the paging procedure.
The paging message is broadcast using Radio Resource procedures on the paging
channel that each idle mode mobile monitors within the cell(s).
Other Radio Resource Procedures
Radio resource procedures are extremely comprehensive and cover a wide range of
requirements. Some of the procedures not dealt with here include:
Power control (uplink and downlink)
Handovers (can be extremely complex in UMTS/W-CDMA)
Connection release
Packet mode procedures
Radio Resource Procedures for UMTS (including HSDPA)
UMTS (Universal Mobile Telecommunication System) procedures follow the
general requirements for GSM and GPRS, except that the radio interface and
channel structure are more complex and therefore require more (and more complex)
procedures. This is also true for HSDPA (High-Speed Downlink Packet
Access), which is a specific implementation of W-CDMA used on the UMTS
radio interface.
The mobility management (MM) and connection management (CM) procedures
are essentially very similar to those discussed above, except that more options
are generally available with UMTS because of the multimedia-capable nature of
the connections. In fact, the procedures for the GSM family of technologies are
contained within a common set of documents (available through the Third Generation
Partnership Project [3GPP] Web site at www.3GPP.org).
The documents are arranged such that all procedures relating to MM and CM
will be in a single document, irrespective of access technology.
Radio resource (RR) management is where the main differences occur between
the technologies and, in this case, the procedures for UMTS (W-CDMA) are separated
from those for GSM, GPRS, and EDGE by the use of different documents
detailing the RR procedures.
First, the radio elements are known as the Node B, which is equivalent to
the BTS in GSM, GPRS, and EDGE, and the radio network controller (RNC),
which is equivalent to the BSC. The term “radio network subsystem” (RNS)
is used in place of the base station subsystem (BSS) used in GSM, GPRS, and
EDGE.
To illustrate just two of the major differences between UMTS (W-CDMA)
and GSM, GPRS, and EDGE, two procedures relating to radio resources (RR) are
described below.
Procedure Sequences
For all cellular systems, each transaction (incoming or outgoing call, data session,
text message, etc.) carried out by the user requires a number of separate procedures
to occur in a set sequence. Each transaction will have its own unique requirements,
but the general sequence will usually be common to all transactions.
The general sequence used for the GSM family of technologies is shown in
At this stage, this sequence ignores the complex requirement for setting
up the radio resources. In reality, the radio resource procedures would occur
within the sequence shown at any point where there is a requirement to allocate,
change, or release radio connections.
Note that the standard sequence illustrates the required procedures in six identifiable
steps. This sequence is referred to as the elementary procedure. Before any
communication with the core network, there must be a radio connection in place.
The mobile must also identify the user to the network prior to any service request
being granted.
The first step in the sequence is the assignment of an appropriate channel, which
may be after a paging message has been received from the network in case of an
incoming call. This is followed by the mobile handset requesting the service that is
required, as well as the security procedures (authentication of the user, and ciphering
of the radio channel). Both security procedures are optional; and although
available in most networks, there are exceptions.
These mobility management procedures are used for establishing a mobility
management (MM) connection with the core network, including the authentication
of the user. Once complete, connection management (CM) procedures are used
to set up and manage the transaction itself, including establishing outgoing or
incoming calls, setting up and managing data sessions, or sending or receiving a
text message. Once complete, all relevant channels will be released.
The elementary procedures will be initiated while a handset is in idle mode,
requiring it to move into dedicated mode for the duration of the sequence, before
falling back to idle mode once the sequence is complete. If another transaction
is required while one is in progress, the mobile uses the existing MM procedures
already in place as the basis for the new transaction. For example, no further security
procedures, or even a paging message, will be required for a mobile that receives
a text message while in the middle of a voice call. For GPRS and UMTS packetdata
operation, similar considerations apply.
text message, etc.) carried out by the user requires a number of separate procedures
to occur in a set sequence. Each transaction will have its own unique requirements,
but the general sequence will usually be common to all transactions.
The general sequence used for the GSM family of technologies is shown in
At this stage, this sequence ignores the complex requirement for setting
up the radio resources. In reality, the radio resource procedures would occur
within the sequence shown at any point where there is a requirement to allocate,
change, or release radio connections.
Note that the standard sequence illustrates the required procedures in six identifiable
steps. This sequence is referred to as the elementary procedure. Before any
communication with the core network, there must be a radio connection in place.
The mobile must also identify the user to the network prior to any service request
being granted.
The first step in the sequence is the assignment of an appropriate channel, which
may be after a paging message has been received from the network in case of an
incoming call. This is followed by the mobile handset requesting the service that is
required, as well as the security procedures (authentication of the user, and ciphering
of the radio channel). Both security procedures are optional; and although
available in most networks, there are exceptions.
These mobility management procedures are used for establishing a mobility
management (MM) connection with the core network, including the authentication
of the user. Once complete, connection management (CM) procedures are used
to set up and manage the transaction itself, including establishing outgoing or
incoming calls, setting up and managing data sessions, or sending or receiving a
text message. Once complete, all relevant channels will be released.
The elementary procedures will be initiated while a handset is in idle mode,
requiring it to move into dedicated mode for the duration of the sequence, before
falling back to idle mode once the sequence is complete. If another transaction
is required while one is in progress, the mobile uses the existing MM procedures
already in place as the basis for the new transaction. For example, no further security
procedures, or even a paging message, will be required for a mobile that receives
a text message while in the middle of a voice call. For GPRS and UMTS packetdata
operation, similar considerations apply.
GPRS Connections
To move information from content and application servers to the handset and vice
versa, a path through the network must be defined. This is achieved using the PDP
context procedure, where the handset, SGSN, and GGSN all store data relating to
this virtual connection (Figure 3.26).
The GGSN defines the gateway to the content — maybe the Internet, MMS
server, or a WAP gateway. The GGSN is identified by a special identity known as
the Access Point Name — effectively a URI (Universal Resource Indicator, as used
for Web pages, etc.).
Because billing and other administrative functions may be based on this
GGSN, it does not make sense in most instances to change this gateway dynamically.
Hence, even when a user is roaming abroad, the GGSN is usually located in
the subscriber’s home network, and a path is defined through the serving networkand an inter-PLMN backbone network (incorporating GPRS Roaming Exchanges
(GRX)), to the home network. The border gateways define the edge of the administratively
separate networks with associated firewalls.
An alternative arrangement may be that the SGSN and GGSN are located in the
same network. This would certainly be the case where the subscriber is attached via
the user’s home network, but may also be true, for example, where connection settings
in the handset for Internet access use a generic APN (access point name), shared by
different operators, allowing access to the nearest GGSN (in the serving network).
Using different procedures, the connection can be maintained. If necessary, the
PDP context information can be moved from SGSN to SGSN without having to
reestablish either the connection or the PDP context.
versa, a path through the network must be defined. This is achieved using the PDP
context procedure, where the handset, SGSN, and GGSN all store data relating to
this virtual connection (Figure 3.26).
The GGSN defines the gateway to the content — maybe the Internet, MMS
server, or a WAP gateway. The GGSN is identified by a special identity known as
the Access Point Name — effectively a URI (Universal Resource Indicator, as used
for Web pages, etc.).
Because billing and other administrative functions may be based on this
GGSN, it does not make sense in most instances to change this gateway dynamically.
Hence, even when a user is roaming abroad, the GGSN is usually located in
the subscriber’s home network, and a path is defined through the serving networkand an inter-PLMN backbone network (incorporating GPRS Roaming Exchanges
(GRX)), to the home network. The border gateways define the edge of the administratively
separate networks with associated firewalls.
An alternative arrangement may be that the SGSN and GGSN are located in the
same network. This would certainly be the case where the subscriber is attached via
the user’s home network, but may also be true, for example, where connection settings
in the handset for Internet access use a generic APN (access point name), shared by
different operators, allowing access to the nearest GGSN (in the serving network).
Using different procedures, the connection can be maintained. If necessary, the
PDP context information can be moved from SGSN to SGSN without having to
reestablish either the connection or the PDP context.
Making Calls
Calls to Mobile Networks
Making a call to a mobile network involves keying in the called subscriber’s
MSISDN (mobile subscriber’s ISDN) number. This number routes the call to the
called subscriber’s home network via a gateway mobile switching center (GMSC).
Here, signaling interactions with the home location register (HLR) occur. The
HLR, in turn, interacts with the visitor location register at the mobile switching
center at which the called subscriber is currently registered.
Eventually, although it takes very little time, new routing information is sent
back to the GMSC to replace the subscriber’s MSISDN number. The new information
allows the call to be routed to the network in which the called subscriber is
currently registered and, more specifically, to the serving MSC (either at home or
abroad [roaming cases]).
Calls from Mobile Networks
For outgoing calls from a mobile network, the serving MSC acts as a local exchange
for the subscriber that is making the call — with the call being routed directly from
the serving MSC (rather than having to route back through the subscriber’s home
network if abroad).
In all cases, however, the call is in accordance with any service information
being held in the VLR (having been previously sent from the subscriber’s HLR
when first registering at this MSC). This may include such restrictions as call barring
or advanced interactions required for prepaid subscribers
Making a call to a mobile network involves keying in the called subscriber’s
MSISDN (mobile subscriber’s ISDN) number. This number routes the call to the
called subscriber’s home network via a gateway mobile switching center (GMSC).
Here, signaling interactions with the home location register (HLR) occur. The
HLR, in turn, interacts with the visitor location register at the mobile switching
center at which the called subscriber is currently registered.
Eventually, although it takes very little time, new routing information is sent
back to the GMSC to replace the subscriber’s MSISDN number. The new information
allows the call to be routed to the network in which the called subscriber is
currently registered and, more specifically, to the serving MSC (either at home or
abroad [roaming cases]).
Calls from Mobile Networks
For outgoing calls from a mobile network, the serving MSC acts as a local exchange
for the subscriber that is making the call — with the call being routed directly from
the serving MSC (rather than having to route back through the subscriber’s home
network if abroad).
In all cases, however, the call is in accordance with any service information
being held in the VLR (having been previously sent from the subscriber’s HLR
when first registering at this MSC). This may include such restrictions as call barring
or advanced interactions required for prepaid subscribers
WLAN and Mobile Networks
The existing GPRS/GSM and newer 3G networks have for a long time offered data
services to their subscribers.
Original circuit-switching data at rates of 9.6 kbps do not allow a great deal
of flexibility and severely restrict the service and content that can be offered. The
advent of GPRS has improved this matter significantly. The packet-switching service
can offer much higher rates to the user and at the same time offer resource
efficiencies to the network operator. However, the data rates are still in the range 10
to 40 kbps. Even if EGDE is deployed in the network, the data rate will only be a
maximum of hundreds of kilobits per second. The advent of 3G networks improves
on this data rate, thus allowing a greater range of services to the users.
These data rates, no matter how impressive, are simply blown away by the rate
available through WiFi hotspots — where typical data rates can be as much a
2 Mbps. The obvious difference here is that the cellular networks are providing
wide area coverage for voice and data, whereas the WiFi service is limited to a very
specific place and does not yet offer mobility services. There may be advantages to
the cellular operators by allowing some form of interworking between the WiFi
systems and their own networks. It is likely that this can be achieved in several different
ways, depending on available technologies and potential agreements between
WiFi and cellular operators.
Some cellular operators have formed alliances with the WiFi service providers,
allowing the cellular subscriber access to the hotspots under the single mobile
subscription. Mobile phone manufacturers are already producing equipment that
supports the WiFi radio in multi-mode devices. This allows the phone itself to use
the WiFi hotspot for data download or even in some cases to make phone calls
using VoIP protocols.
In due course it may become common for the cellular operators themselves to
build and maintain their own WiFi infrastructure, connecting directly to the mobile
core network. Using mobile IP and a 3G core network, this offers users seamless
mobility between mobile networks and WiFi systems under a single subscription.
WiFi is illustrated as a stand-alone technology that connects
directly to the Internet, or as an integral part of the cellular operator’s network —
effectively providing alternative access. Note that IMS refers to the IP Multimedia
Subsystem that is designed to provide support for advanced multimedia services.
services to their subscribers.
Original circuit-switching data at rates of 9.6 kbps do not allow a great deal
of flexibility and severely restrict the service and content that can be offered. The
advent of GPRS has improved this matter significantly. The packet-switching service
can offer much higher rates to the user and at the same time offer resource
efficiencies to the network operator. However, the data rates are still in the range 10
to 40 kbps. Even if EGDE is deployed in the network, the data rate will only be a
maximum of hundreds of kilobits per second. The advent of 3G networks improves
on this data rate, thus allowing a greater range of services to the users.
These data rates, no matter how impressive, are simply blown away by the rate
available through WiFi hotspots — where typical data rates can be as much a
2 Mbps. The obvious difference here is that the cellular networks are providing
wide area coverage for voice and data, whereas the WiFi service is limited to a very
specific place and does not yet offer mobility services. There may be advantages to
the cellular operators by allowing some form of interworking between the WiFi
systems and their own networks. It is likely that this can be achieved in several different
ways, depending on available technologies and potential agreements between
WiFi and cellular operators.
Some cellular operators have formed alliances with the WiFi service providers,
allowing the cellular subscriber access to the hotspots under the single mobile
subscription. Mobile phone manufacturers are already producing equipment that
supports the WiFi radio in multi-mode devices. This allows the phone itself to use
the WiFi hotspot for data download or even in some cases to make phone calls
using VoIP protocols.
In due course it may become common for the cellular operators themselves to
build and maintain their own WiFi infrastructure, connecting directly to the mobile
core network. Using mobile IP and a 3G core network, this offers users seamless
mobility between mobile networks and WiFi systems under a single subscription.
WiFi is illustrated as a stand-alone technology that connects
directly to the Internet, or as an integral part of the cellular operator’s network —
effectively providing alternative access. Note that IMS refers to the IP Multimedia
Subsystem that is designed to provide support for advanced multimedia services.
Subscribe to:
Posts (Atom)