Introduction to IMS

1.1 What is IMS?
IP Multimedia Subsystem (IMS) is a set of specifications that describes the Next Generation Networking (NGN) architecture for implementing IP based telephony and multimedia services. IMS defines a complete architecture and framework that enables the convergence of voice, video, data and mobile network technology over an IP-based infrastructure. It fills the gap between the two most successful communication paradigms, cellular and Internet technology. Do you ever imagine that you can surf the Web, play an online game or join a videoconference no matter where you are using your 3G handheld device? This is the vision for IMS; to provide cellular access to all the services that the Internet provides.
1.2 History of IMS
IMS was initially defined by the 3rd Generation Partnership Project (3GPP), which is a collaboration agreement among a number of telecommunications standards bodies, as part of their standardization work for supporting GSM networks and radio technology evolution. IMS was first introduced in 3GPP Release 5, where "Session Initiated Protocol" (SIP), defined by the Internet Engineering Task Force (IETF), was chosen as the main protocol for IMS. It has been further enhanced in Releases 6 and 7 of 3GPP to include additional features like presence and group management, interworking with WLAN and CS based systems, and Fixed Broadband access.
Another standards body, 3rd Generation Partnership Project 2 (3GPP2), also standardized their own IMS. 3GPP2 was born to evolve North American and Asian Cellular Radio-telecommunication Intersystem Operations into a third-generation system. The initial release of 3GPP2 specifications on IMS largely adopts from 3GPP Release 5. The two IMS network defined by two organizations are fairly similar but not exactly the same. 3GPP2 added appropriate adjustments for their specific issues. Nevertheless, the purpose of both organizations is to ensure the IMS applications will work consistently across different network infrastructures.
In addition to the 3GPP and 3GPP2, Open Mobile Alliance (OMA) plays an important role on specifying and developing IMS service standardization. The services defined by OMA are built on top of IMS infrastructure, such as Instant Messaging (IM), Presence service, and Group Management Service.
1.3 Benefits of IMS
We've discussed the idea of IMS as a way to offer Internet services everywhere using cellular technology. You may already be very familiar with accessing Internet services like Web access, email, or instant messaging via a 2.5G and 3G cellular phone. As a result, you may wonder why we need IMS.
The benefits of IMS over the existing cellular network infrastructure can be demonstrated in the following four aspects.

• IMS provides a common platform to reduce time-to-market for rolling out new multimedia services: One of the biggest challenges in today's communication network is to improve the long and costly process for creating a new service. Service providers are looking for ways to reduce the time-to-market for rolling out new multimedia services. The IMS infrastructure solves this problem by providing the standardized platform and reusable components. The standardized interface and common features provided by IMS infrastructure enables service providers to easily adopt a service created by third parties and create a service that integrates with many services effectively. In addition, with the standardized interface provided by IMS, the service is no longer solely provided by a single provider; any provider who implements the standardized interface can provide the service. The multi-vendor service creation industry leads to an open market, and allows service providers to choose the most effective way to roll out new services.
• IMS provides multimedia services with Quality of Service (QoS) enablement:: Although the dramatically increased bandwidth in 3G cellular networks provides a much faster and more reliable Internet access compared with 2.5G cellular network, there are no guarantees about the quality of the services. A 3G cellular network provides what is known as "best effort, which means the network will do its best to ensure the required bandwidth, but there is no guarantee it will remain at the same level. Consequently, the bandwidth of a particular connection can vary significantly over time. In order to solve this problem, Quality of Service (QoS) mechanisms were developed in order to provide certain guarantee levels of network bandwidth during transmission instead of the so called "best effort". IMS specifies enablement of Quality of Service within the IP network and takes advantage of th QoS mechanism to improve and guarantee the transmission quality.
• IMS allows operators to charge multimedia session appropriately: If a user uses videoconference over the 3G cellular network, there is usually a large data transfer that consists of audio and video. This is usually expensive since the operator will generally charge by the number of bytes transferred. On the other hand, if the operator is willing to provide a different charging scheme based on the actual service type, it may be more beneficial to the users. The advantage of IMS is that it provides information about the service type being invoked by the user and thus allows the operators to determine how to charge the users based on service types, i.e. they can choose to charge user by the number of bytes transferred, by the session duration (time-based), or perform any new type of charging.
• IMS allows all services to be available irrespective of the users' location: A typical, and particularly annoying problem when working with cellular technology is that some of the services will not be available when the user is roaming in another country. To resolve this problem, IMS uses Internet technologies and protocols in order to allow users to move across the countries and still be able to execute all the services as if they were from their home networks.

1.4 IMS architecture
IMS architecture supports a wide range of services that are enabled based on SIP protocols. As you can see from Figure 1-1 below, an IMS architecture delivers multimedia services that can be accessed by a user from various devices via an IP network or traditional telephony system. The underlying network architecture can be divided into three layers (Device Layer, Transport Layer, and Control Layer) plus the service layer and will be introduced from bottom to top respectively.

• Device Layer: The IMS architecture provides a variety of choices for users to choose end-point devices. The IMS devices such as computers, mobile phones, PDAs, and digital phones are able to connect to the IMS infrastructure via the network. Other types of devices, such as traditional analog telephone phones, although they are not able to connect to an IP network directly, are able to establish the connection with these devices via a PSTN Gateway.
• Transport Layer: The transport layer is responsible for initiating and terminating SIP sessions and providing the conversion of data transmitted between analog/digital formats and an IP packet format. IMS devices connect to the IP network in the transport layer via a variety of transmission media, including WiFi (a wireless local area networks technology), DSL, Cable, SIP, GPRS (General Packet Radio Service is a mobile data service), and WCDMA (Wideband Code Division Multiple Access, a type of 3G cellular network). In addition, the transport layer allows IMS devices to make and receive calls to and from the PSTN network or other circuit-switched networks via the PSTN gateway.
• Control Layer: The Call Session Control Function (CSCF), which is a general name that refers to SIP servers or proxies, is one of the core elements in the control layer. CSCF handles SIP registration of the end points and process SIP signal messaging of the appropriate application server in the service layer. Another element in the control layer is the Home Subscriber Server (HSS) database that stores the unique service profile for each end user. The service profile may include a user's IP address, telephone records, buddy lists, voice mail greetings and so on. By centralizing a user's information in HSS, service providers can create unified personal directories and centralized user data administration across all services provided in IMS.
• Service Layer: On top of the IMS network architecture, we have the service layer. The three layers described above provide an integrated and standardized network platform to allow service providers to offer a variety of multimedia services in the service layer. The services are all run by application servers. The application servers are not only responsible for hosting and executing the services, but also provide the interface against the control layers using the SIP protocol. A single application server may host multiple services, for example, telephony and messaging services run on one application server; one advantage of this flexibility is to reduce the workload of the control layer. There are many application servers providing different services, and three core application servers of IMS will be highlighted below.
  • Presence server: A "Presence server" provides the services to collect, manage and distribute the real time availability and the means for communicating among users. It allows users to both publish their presence information and subscribe to the service in order to receive notification of changes by other users.
  • Group List Management server: A "Group List Management server" provides services that allow users or administrators the ability to manage, create, modify, delete and search the network-based group definition and the associated lists of members. It also maintains the access permissions and other specific properties associated with the groups and the members. It is also used to provide buddy lists for instant messaging or other services.
  • Instant Messaging Server: An "Instant Messaging server" provides a communication service that allows users to send and receive messages instantly. Users are able to deliver the messages containing rich text, images, audio, video, or the combination of these over an IP network. It has been widely used in today's Internet community, and IMS will bring the same service experience into the mobile world.

Figure 1-1. IMS Architecture Diagram

Service providers are eager to allow their customers to be able to develop and implement services that leverage the existing the service resources described above. However, many enterprise application developers may have an IT background but are not familiar with those complex telephone protocols (e.g. SIP, ISDN, SS7 etc.); and they need a simple API for services creation and development. It then falls to Parlay X SOA (Service-Oriented Architecture) Web services, which have been defined by Parlay Group in 2003 in order to provide a set of simple-to-use, high-level, telecom-related Web services. The idea with Parlay X is to provide Web services in a context that is already widely adopted and understood by a large number of developers and programmers, and to do so in an environment where there are a variety of development tools available. With the Parlay X SOA Web services interfaces, the application developers can access and leverage the existing IMS services more easily through Web services. The Parlay X SOA Web services are connected to the telecommunication network either via the Open Services Access - Gateway (OSA-GW) or directly through data service components over IP Protocols.

An introduction to the SIP protocol

This article will drill down into the way the Session Initiation Protocol (SIP) works, and it should serve as a good starting point for really learning SIP. If you haven't already done so, you are encouraged to read the previous article, although it's not a prerequisite. This introduction also covers the latest SIP extensions and changes, so it gives a complete view of the protocol's current state, rather than just the basic, underlying RFC.
Session Initiation Protocol (SIP) is a VoIP signaling protocol. As its name suggests, it has everything to do with setting up sessions, which means it has the responsibility for starting a session after you dial a number (or double-click, in some cases). As such, SIP's role also includes maintaining user registrations with a server, defining session routing, handling various error scenarios, and, of course, modifying and tearing down sessions.
We'll present this introduction in two parts. In the first part, we'll focus on the SIP foundation layers. These layers allow creating a network of SIP servers. In the next article, we will go through the way a phone communicates with the rest of the world using this server network, based on the same foundation layers.

Message Structure

SIP shares the same message structure as HTTP and RTSP. As a result, most of the text description here would fit these protocols as well. Each message is either a request or a response. All messages are text-based and have the following form:

• First line
• Headers
• Empty line
• Optional body

The first line is different for a request and a response. A request's first line uses the following format:
<method (request type)> <URI (address/resource)> <version>
For example, a SIP request's first line can be:
REGISTER sip:arstechnica.com SIP/2.0
A response comes in the form of:
<version>
The version is the same in all messages. The code is a 3-digit value, and the reason phrase could be any text describing the nature of the response. A proper first line in the response could be:
SIP/2.0 200 OK
It's easy to scan the first characters of a message to detect whether it's a request or a response ("/" is not a valid character for the method field, therefore even a generic parser could differentiate a request from a response).
Next come the headers of the message. Some headers contain vital information and thus are mandatory, but many headers are optional. Each header has a name and a value, and some have parameters. For example:
Contact: sip:gilad@voxisoft.com;Expires=2000
Contact is the header name, sip:gilad@voxisoft.com is the value, and expires=2000 is a parameter. Other parameters may appear separated by semicolons.
Some headers may appear just once in a message, and some may appear multiple times. An equivalent approach to using multiple headers is to separate each value-parameter set with a comma. Some headers have a compact form for which the header name is shorter. For example, you can use "m" instead of "Contact".
After the last header, there's an empty line followed by the body of the message. The body could be anything, even binary information. The header Content-Type specifies the type of the message body. In order to know the length of the body, you have to look at the Content-Length header. (If the transport type is UDP, then the Content-Length header is not mandatory. It is, however, mandatory for TCP). One common use of the body is to encapsulate the media negotiation protocol within the SIP message.
That's pretty much what you need to know in order to understand the basic structure of SIP. It is rather straightforward, and anyone who is already familiar with protocols that have similar structure will feel right at home. Of course, we still have to understand what this text means and what a SIP device should do with the messages it sends and receives.

Transport Types

By default, SIP messages are sent on port 5060 if they're unencrypted. Encrypted messages are sent over port 5061. One can specify a port other than the default within the SIP address and override this default value.
SIP mandates support for both UDP and TCP, but it can successfully operate on practically any transport type. It defines different behavior per transport only when the characteristics of the specific transport require it to do so. For example, UDP does not guarantee delivery, so SIP retransmits the messages. In TCP, such retransmission is really unnecessary (and confusing), so no one should retransmit a message. For the most part, other than the transaction layer (detailed in the next sub-section), almost no other component changes its behavior due to the transport.
In fact, because SIP operates hop-by-hop (clients do not usually communicate directly, but rather use proxies along the signaling path to send and receive messages), each hop could change the transport type. So a client may receive a message over TCP even if the original message was sent over UDP. SIP's transport type independence enables the possibility of defining new transport types that were not originally included when SIP itself was first defined. For example, RFC 4158 is a very short RFC that defines SIP over SCTP.
For connection-based transports (e.g., TCP and SCTP), the state of the connections is maintained. Connections are kept open and reused to save time and resources. The recommendation is to keep a connection open for at least 32 seconds after the last message, but in practice it's application-defined. Because there is no defined limit for the number of different SIP messages that one can send on a connection, two devices such as proxies usually have one or very few connections between them.

NAT vs. VoIP

One of the main challenges that VoIP protocols have encountered, and SIP is no exception, is the existence of NAT devices. NATs usually aggregate several IP addresses (in many cases within a private network) to a few external IP addresses, mapping different traffic from different IP addresses to different ports. (This is a very simplistic description of NATs; there are in fact several ways NATs can work, but this is a common one that's easy to describe). In order to map different addresses to IP and ports, NATs usually maintain a dynamic mapping table. If traffic from 172.16.1.1 with port 5060 maps to a public IP address with port 10000, the NAT will keep this mapping as long as it has a flow of packets from that address. If the flow stops, the NAT will remove this mapping after a configurable amount of time to allow another internal IP and port to use the external IP and port combination.
VoIP's problem arises because signaling protocols are as minimalistic as possible in terms of traffic. In order to allow the rest of the world to locate a device, the device first registers by sending a REGISTER request. A response from the registrar accepting this registration will usually tell the device that its registration is valid for a long time, most commonly an hour.
Now, suppose a NAT is located between the client and the server. When the REGISTER request is sent, the NAT maps the device's internal IP and port to an external one. When the response is sent back, the NAT has the proper mapping to the original IP and port. If the client does not send any packets to the server (for example, does not make a call), the NAT may remove the mapping it created during the registration. The outcome of this scenario is that incoming calls cannot reach the client. The proxy server receiving the request to the registered client cannot reach the internal IP address without the NAT mapping.
It's because of this NAT issue that RFC 5626 was introduced. This RFC defines the techniques that a client can use to maintain the NAT mapping. It introduces the concept of a flow that should be maintained by the registering client. The client sends two empty lines (carriage return and line feed, or CRLF) on connection-oriented flow (TCP and SCTP) and expects to receive from the server a single empty line as a response. For connection-less transports, the client maintains the flow by using STUN (defined by RFC 5389)

Transaction layer

The SIP RFC divides the architecture into layers. We actually went through two of the layers in the discussion above: the first was the syntax and encoding layer that defines the message structure, and the second was the transport layer. Now it's time to inspect the contents of the SIP message by taking a look at the transaction layer.

The SIP layers

Every SIP message is associated with a single transaction. Similar to HTTP, messages are either requests or responses, but unlike HTTP, matching responses to requests is not simple. HTTP uses TCP as its transport, so you can match a response based on the order of the requests. But a SIP transaction can have more than a single response, and, in some cases, more than one request. When a SIP device sends a request, it acts as a user agent client (UAC). The recipient of the request, the one that sends the response, acts as a user agent server (UAS). The layer above the transaction layer is named "transaction user" or TU. Let's look at a SIP request that a UAC can initiate:
REGISTER sip:arstechnica.com SIP/2.0
Via: SIP/2.0/UDP home.mynetwork.org;branch=z9hG4bKmq0Tgb
To: sip:me@arstechnica.com
From: sip:me@arstechnica.com;tag=m25caI4
Call-ID: n35nzlsdjfb3@home.mynetwork.org
CSeq: 153 REGISTER
Contact: sip:me@home.mynetwork.org
Max-Forwards: 70

We have already seen that REGISTER is the method (type of request), sip:arstechnica.com is the request-URI, and SIP/2.0 is the version. All the headers above are the mandatory. At this point, we'll cover the headers that are important to the transaction layer, and we'll cover the rest of them when we get to the way proxies and registrars work. First, let's examine the Via header.
The Via header has a parameter called "branch" with an odd value. The first 7 letters (z9hG4bK) are fixed, and they help identify this as a SIP transaction based on RFC 3261. These letters, often referred to as the "magic cookie", would not appear with a request that is using the previous SIP RFC, which has different transaction matching rules. We'll only look the cases that have the magic cookie because it's very rare today to encounter an implementation that has not caught up with the latest spec.
After the seven letters, the rest is just a random string. Every time you see a different branch value it's a different transaction; conversely, if both messages have the same branch value, then they should be the same transaction. One exception to this rule is if the method of the CSeq header is different. This is because the CANCEL method uses the same branch value to identify which transaction you should cancel. So, to fully match two messages to the same transaction, both the branch and CSeq method have to match. Naturally, this means that responses to a request will have matching values.
Before moving on, one final note on the Via header. When we refer to this header, we actually refer to the first, or topmost, Via header. Via is one of those headers that can appear multiple times within a message. The reason for this will become clear in the proxy section, but it's important to note that you always match the transaction based on the first Via header and ignore the rest.
The UAS sends a response to an incoming request. SIP responses are divided into 6 different classes, and the first digit of the 3-digit response code identifies each class. A 1xx response means any response in the range of 100 to 199. The response types are:

• 1xx - Provisional response, which indicates that the request is handled, but without a final response yet. For example, 180 Ringing is a common provisional response.
• 2xx - Successful response. The most common one is 200 OK.
• 3xx - Redirect response. A client receiving this response would know the user moved to a different location. For example, a phone may redirect all its calls to a different address by responding back with a 302 Moved Temporarily.
• 4xx - Client error, which means that the request cannot be fulfilled and the sender should modify its request. For example, you can send 401 Unauthorized if the request does not contain the correct user credentials.
• 5xx - Server error, which usually indicates that the error is not related to the request, but to the state of the server or the server capabilities. For example, you would send 501 Not Implemented when receiving an unknown method.
• 6xx - Global error, which indicates the request cannot be fulfilled by any server. It would be rare to receive such responses, as it requires having global knowledge of the network.

SIP dedicates special attention to making sure the response is sent back to the same source IP that sent the request. This is, in fact, one of the roles of the transport layer, not the transaction layer. The transport layer does this by adding a "received" parameter to the top Via header of the request. Later, RFC 3581 defined a new parameter called "rport" to ensure that the response is sent back to the same originating port. Both of these additions were aimed at making SIP work over NAT. SIP's default behavior is to send the response back on the same connection of the request, but in case it fails to do so, it will attempt to open a new connection. Therefore, none of the layers can assume a single transaction uses a single connection. A possible SIP response to the request above is:
SIP/2.0 200 OK
Via: SIP/2.0/UDP home.mynetwork.org;branch=z9hG4bKmq0Tgb;received=172.16.75.2
To: sip:me@arstechnica.com;tag=q8K2f1zv
From: sip:me@arstechnica.com;tag=m25caI4
Call-ID: n35nzlsdjfb3@home.mynetwork.org
CSeq: 153 REGISTER
Contact: sip:me@home.mynetwork.org;Expires=3600

The example shows a successful response, but a UAS may choose to send an error response, such as the well-known "404 not found," in an instance where the user is not known. Both the UAC and UAS maintain a state machine for each transaction, and each state machine has timers. Timers are necessary in case the other side does not respond in time, and they're also required in case the layer above the transaction layer does not send a proper event and leaves the transaction open.
Ultimately, SIP has built each of its layers to be as decoupled as possible from the other layers, and an error in any one layer has minimal impact on the rest. This separation makes it easy for programmers to separate their software into smaller components.
The protocol distinguishes between 4 types of transactions, so it has 4 different types of state machines: client INVITE, client non-INVITE, server INVITE and server non-INVITE. We haven't mentioned the INVITE method yet, and for a good reason. INVITE is a method used to generate a call, and these lower layers do not maintain the call state. However, this transaction is different because calls have a 3-way handshake that affects the state-machine. Let's start with a diagram of the client non-INVITE transaction state-machine:

The Non-INVITE client transaction

Most of the timers are for retransmissions in UDP, and they are disabled in TCP. An additional timeout timer exists in case no response is received. Transactions normally exist for 32 seconds until they time out. The equivalent server state-machine is quite similar; it receives a request, sends it to the TU, sends the response back, and handles retransmissions if required. It should be noted that some of the non-INVITE transaction definitions were updated by RFC 4320.
Let's cover the 3-way handshake. The UAC sending the INVITE waits for a response, but this time to complete the handshake it sends an ACK request back to the server. ACK has no response, as it's the 3rd message in the handshake. This fact forces ACK to be an exception to many of the rules.
When a client receives a successful (2xx) response type, it means a call was created and it will send the ACK in a new transaction. A failure response (300-699) means the ACK will be on the same transaction. The reason for this lies in the behavior of the upper layers. We will see that proxies are not aware of a call state, and those that are stateful maintain just the transaction state. There are scenarios in which a proxy would need to ACK a failed response, but it cannot ACK a successful response because that would require understanding call-related information. The INIVITE client state machine is as follows:

The INVITE client transaction

 

User location

Let's step out of the SIP layers and see what we have so far: using the layers, we can now create and receive SIP transactions.
One basic requirement in SIP is for phone devices to be able to register their location with a registrar. Using this registration information, we can send a request to a server and this request would reach the intended recipient. Let's go back to the previous example:
REGISTER sip:arstechnica.com SIP/2.0
Via: SIP/2.0/UDP home.mynetwork.org;branch=z9hG4bKmq0Tgb
To: sip:me@arstechnica.com
From: sip:me@arstechnica.com;tag=m25caI4
Call-ID: n35nzlsdjfb3@home.mynetwork.org
CSeq: 153 REGISTER
Contact: sip:me@home.mynetwork.org
Max-Forwards: 70

We already covered the first two lines, so let's now look at the rest.

• The Contact header tells the registrar the actual address of the device; many times you'll see an IP rather than a domain name in this field.
• The To header tells the registrar the address of record (usually referred as the AOR). AOR is the public SIP address, the same as my email address.
• The From header usually has the same value as the To. (It would be different in case someone is registering on behalf of someone else, but this case is rare.)
• Call-ID is an identifier that groups together a series of messages. Two different registrations should have different Call-ID values, but re-registrations should have the same Call-ID values. To differentiate the re-registrations, the client would increment the CSeq value.
• We'll leave the Max-Forwards explanation for the last section.

The client may also add an expiration value to the registration, either by adding a new Expires header or by adding an Expires parameter to the contact header. This is a recommended value to the server, because the server is the party that chooses the expiration time and sends it in the successful response. The expiration time may not be higher than the client-requested value, and if the value is below the minimum acceptable value then the registrar should reject the request.

Registering multiple user devices

A user is not bound to register with only one device, since it's possible that the user owns several SIP-capable devices and wants to be able to use the same SIP address simultaneously. A simple example involves two phones, one a desk phone and the other a cell phone. When someone calls the public SIP address, both phones would ring. To accomplish this, both devices register with the same AOR but different contact values. The registrar receiving these registrations maintains both associations. Requests arriving to the user AOR would fork to both devices. In some cases, it may make sense that both devices would create a session, but most of the time, this would be a call and thus the first device that answers would establish the call. Anyone who has a cell phone and a car phone with the same phone number is quite familiar with this scenario.
The fact that SIP lets several devices register originally worked out well, but then more complex scenarios started to come up. Suppose a user with two devices is in a conversation, and the person on the other end transfers the call to a third party. In SIP, it would mean the third party would send a request to the first user, but if it were to use the AOR, the request would fork to both devices. A device that is not active in the call would not be able to transfer a non-existent call. In this case, you might suggest using the device IP value, but many times, this will be a non-routable IP address, and the only way to reach it is via a server that has access to this private network.
For such scenarios, an extension called GRUU (Globally Routable User Agent URI) was introduced, defined in RFC 5627. When a user registers with a device that supports this extension, a header parameter named "+sip.instance" with a unique identifier is added to the contact header. The registrar creates two GRUUs for that instance: a public GRUU with the identifiable AOR, and a temporary GRUU to be used in case the user wants to make an anonymous call. Both these GRUUs are SIP addresses with a "gr" parameter. Now when there's a call with one of the devices, the contact address would have the GRUU SIP address. A transfer request would use this value, and because the server has a mapping between this GRUU and the actual device instance, the request reaches a single device participating in the call rather than the other devices.

Locating servers

A SIP client that wishes to register to sip:arstechnica.com needs to resolve this address. SIP uses DNS to do that, but simply resolving the address to an IP is not enough. Therefore, SIP uses DNS to discover everything it needs to send the request. All the procedures I describe in this section are detailed in RFC 3263.
First, the client needs to discover the preferred transport type. For example, a client that supports UDP, TCP and SCTP performs a NAPTR query (defined in RFC 3403) for arstechnica.com. A response for such query may be:

   ;          order pref flags service      regexp  replacement
      IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.arstechnica.com.
      IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.arstechnica.com.
      IN NAPTR 80   50  "s"  "SIP+D2S"      ""  _sip._sctp.arstechnica.com.
      IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.arstechnica.com.

That means the server supports TLS, TCP, SCTP and UDP in this order. The service value determines the transport type. A client that does not support TLS will choose the second option, "SIP+D2T" which means "SIP over TCP." To use TCP, the client now needs to resolve _sip._tcp.arstechnica.com.
We have the transport type, but now the port is unknown. It is true that the default port is 5060, but this port will only be used if we cannot resolve a different port. To resolve the port, the client performs an SRV query (this type is defined in RFC 2782) for _sip._tcp.arstechnica.com. A possible response to this query may be:

   ;;          Priority Weight Port   Target
       IN SRV  0        1      5060   server1.arstechnica.com
       IN SRV  0        2      5070   server2.arstechnica.com

Now it's finally time to resolve the IP address. The client tries to send the request to server1.arstechnica.com, port 5060 via TCP. To find the correct IP address, the client performs an A query on IPv4 or AAAA query on IPv6. If the transaction times out, then the client should not stop at this point. It should try to send a new request to server2.arstechnica.com, port 5070 and transport TCP. If this also fails, then the client stops because it’s the last SRV record. So, SRV records are not just for resolving the port, but are also useful for server redundancy and load balancing.
Naturally, this elaborate process of doing different DNS queries takes time, and will significantly increase latency if you want to send many SIP messages. Hence, the assumption is that the client caches these DNS results. This is a reasonable assumption, since HTTP clients also cache DNS to improve performance. There are other possibilities for overriding these queries. The first is to use a numeric IP address, but this is not recommended for obvious reasons. The other option is to specify the values in the SIP URI itself. One can specify its address as: sip:arstechnica.com:5060;transport=tcp. This is also not recommended, since changing the values requires changing the URI. Furthermore, the server redundancy supported by the SRV records would not be available.

Proxies

Now let's look at SIP proxies to see how the different pieces fall together. You rarely send signaling messages directly between phone devices. Usually, there's at least one, if not several, proxies along the signaling path, and these proxies are designed to be aware of transactions, not calls. (Such a design is more scalable.)
Proxies act as both UAC and UAS. An incoming request goes to the proxy UAS side, and the proxy then creates a new transaction as a UAC. Responses reach the UAC, and the proxy generates responses as a UAS. Therefore, for an incoming transaction and a corresponding outgoing transaction, the transaction layer maintains two state-machines, and it's the proxy's job to manage the interaction of these two transactions.
Some proxies work in conjunction with a registrar and have access to a shared database. It's such a proxy's job to retrieve a user's public AOR and to resolve its registered contact address. Other proxies simply route the messages. I should note at this point that this section focuses on stateful proxies. The standard also defines stateless proxies, so some of the text here would not apply to those server types.

The Via header, forking, loop prevention

When we went through the transport layer, I added a vague description of the top Via header. Now it's time to address this header in more detail.
A SIP message may contain more than a single Via header. When a proxy constructs a request for a new transaction, it takes the existing message and adds an additional Via header above the existing, topmost Via header. This Via header has a new "branch" parameter value, thus signifying that this is a new transaction and that its address is the proxy's UAC-side address. The UAS receiving this request would send the response based on the top Via header, thereby ensuring that the response goes back to the proxy. If the proxy sends back the response, it sends it without its own Via header, because the original transaction is a different one and has a different top Via header with a different "branch" value. Proxies use a similar mechanism with route and record-route headers,
 In order to send a request to multiple targets, the proxy forks a request. An incoming request may result in several outgoing requests to different targets, each containing a different branch value. Proxies will not forward every failed final response to the UAC because the first final response would cause the UAC to close the transaction. Therefore, the proxy collects the error responses, and if all the outgoing transactions fail, it chooses the most appropriate failed response. A successful response is sent back to the UAC immediately. This is why we saw that an ACK request is part of the transaction for a failed response. For INVITE transactions, the proxy sends out an ACK for failed responses and does not wait until the other responses arrive. On the other hand, the proxy cannot ACK a successful 2xx response to INVITE since this means a new call was created, but the caller is not aware of this yet.
To prevent loops, proxies use the Max-Forwards header. This is the last of the mandatory headers that I skipped in earlier sections. The initial request is sent out with a value, most commonly 70, and every proxy that forwards this request deducts 1 from the value in the request that it sends out. If the value of the Max-Forwards reaches 0 before it reaches the final destination, the UAS sends back a 483 (Too Many Hops) response. It should be noted that a possible amplification vulnerability was later discovered for forking proxies. This was addressed by RFC 5393, which changed some loop detection mechanisms and introduced a new header called Max-Breadth that reduces the number of possible forks a message goes through.
Finally, proxies send out a 100 (Trying) provisional response when they receive a request whose response takes more than 200 ms. This prevents the UAC from retransmitting the request, and it also prevents a time-out event. 100 is a response that is generated by the proxy. If we have more than one proxy, the proxy that receives the 100 message will not forward it. This is because it should have sent its own 100 message prior to receiving it.

An example using proxies

Let's look at an example to wrap up this discussion (non-essential details elided, including the SIP version in the first line of the request and some headers that will be discussed when we cover calls):

This message is sent from Ars Technica's network and reaches the arstechnica.com SIP proxy. The proxy sends out the message to the voxisoft.com SIP proxy and returns a 100 response. Voxisoft's proxy has two registrations and forks the request to two devices (while also sending out a 100 response). Notice that all new requests have a new Via header with a new branch parameter. Also, note that the second message is using TCP as a transport. This is a valid scenario, as we previously discussed, since both transactions have different state machine and one of them may discover a different transport when performing a NAPTR query.
At this point, one device might answer with, for example, 486 (Busy), but the proxy does not forward it because it has another forked message pending; so it just sends an ACK. The ACK has the same branch value since it's the same transaction. ACK is sent only for the INVITE case; if this were a different method then ACK wouldn't be used. The second device sends a 200 OK and this message is sent all the way back to the initiating client. The following illustration shows this process in action:

Finally, the client on the left side sends out an ACK for the 200 OK. This ACK is a new transaction and therefore has a new branch value. The proxies forward the request to the destination, again adding a Via header for each hop.
 

ADSL

ADSL is the acronym for Asymmetric Digital Subscriber Line. ADSL is a loose set of protocols that allows for high speed internet access over normal copper telephone lines or what is more commonly known as POTS (Plain Old Telephone Service). This is possible because the signals are sent digitally instead of through analog waves. ADSL is known as asymmetric because the download and upload speeds are not symmetrical with download speeds being averagely faster than upload speeds. Upstream data speeds are lower because requests for web pages normally do not require a lot of bandwidth.
ADSL provides internet access that is constantly on unlike dial up phone access. That way, your computer remains connected to the internet when it is powered on unless the cable is manually disconnected. ADSL allows for the simultaneous use of normal telephone services (voice), Integrated Service Digital Network (ISDN) and high speed data transmission such as video. ADSL provides much higher bandwidth than traditional dial up connections. Speeds can range from 512Kbps to 9 Mbps.

How ADSL works

ADSL makes use of your existing telephone line. It splits the line into two distinct channels, one for data connection and the other for voice. The ADSL signal requires 2 special modems. One is used at your end while the other is used in the telephone exchange. Each modem is geared to a different frequency. Your telephone line is prepared for ADSL by opening up the copper pair to high frequencies and then routing the digital data in these frequencies to a Digital Subscriber Line Access Multiplexer (DSLAM) which converts this signal to ATM packets. The signal is then sent back to the servers and the server then forwards the request and assigns an IP address to the client.
ADSL modulation exists in two schemes. One is Carrierless Amplitude (CAP) and the other is Discrete Multi-Tone (DMT). These modulation schemes allow data transmission over high frequencies thus increasing internet access speed. The two schemes are used for both upstream and downstream data transmission. However, most modern installations are based on the DMT modulation scheme. The idea behind DMT is to split the bandwidth into a large number of sub channels and allocate data so that the throughput of every single sub channel is maximized.

Advantages of ADSL

1. Unlike traditional dial up connection where one session could only be used by one user, ADSL allows several users to share one account meaning the cost can be split between multiple users.
2. ADSL uses standard telephone lines for digital transmission thus setting the analog transmission signals apart from the digital. This allows normal usage of the telephone facility even as you are browsing the internet.
3. Allows for high speed internet access without the cost of ISDN.
4. ADSL 2 and ADSL 2+ have the advantage that they offer several improvements to ADSL. Some of these improvements include faster data transmission of up to 20 Mbps, dynamic data rate adaptation, standby power saver, better resistance to noise etc.
5. ADSL transfers data digitally and digital data has a higher noise tolerance than analog data.

SS7 Tutorial

Overview

Common Channel Signaling System No. 7 (i.e., SS7 or C7) is a global standard for telecommunications defined by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T). The standard defines the procedures and protocol by which network elements in the public switched telephone network (PSTN) exchange information over a digital signaling network to effect wireless (cellular) and wireline call setup, routing and control. The ITU definition of SS7 allows for national variants such as the American National Standards Institute (ANSI) and Bell Communications Research (Telcordia Technologies) standards used in North America and the European Telecommunications Standards Institute (ETSI) standard used in Europe.
The SS7 network and protocol are used for:

• basic call setup, management, and tear down
• wireless services such as personal communications services (PCS), wireless roaming, and mobile subscriber authentication
• local number portability (LNP)
• toll-free (800/888) and toll (900) wireline services
• enhanced call features such as call forwarding, calling party name/number display, and three-way calling
• efficient and secure worldwide telecommunications
• Learn about our SS7/IP signaling products.  

Signaling Links

SS7 messages are exchanged between network elements over 56 or 64 kilobit per second (kbps) bidirectional channels called signaling links. Signaling occurs out-of-band on dedicated channels rather than in-band on voice channels. Compared to in-band signaling, out-of-band signaling provides:

• faster call setup times (compared to in-band signaling using multi-frequency (MF) signaling tones)
• more efficient use of voice circuits
• support for Intelligent Network (IN) services which require signaling to network elements without voice trunks (e.g., database systems)
• improved control over fraudulent network usage
• Save network operating costs by reducing SS7 links.

Signaling Points

Each signaling point in the SS7 network is uniquely identified by a numeric point code. Point codes are carried in signaling messages exchanged between signaling points to identify the source and destination of each message. Each signaling point uses a routing table to select the appropriate signaling path for each message.
There are three kinds of signaling points in the SS7 network (Fig. 1):

• SSP (Service Switching Point)
• STP (Signal Transfer Point)
• SCP (Service Control Point)

Figure 1. SS7 Signaling Points

SSPs are switches that originate, terminate, or tandem calls. An SSP sends signaling messages to other SSPs to setup, manage, and release voice circuits required to complete a call. An SSP may also send a query message to a centralized database (an SCP) to determine how to route a call (e.g., a toll-free 1-800/888 call in North America). An SCP sends a response to the originating SSP containing the routing number(s) associated with the dialed number. An alternate routing number may be used by the SSP if the primary number is busy or the call is unanswered within a specified time. Actual call features vary from network to network and from service to service.
Network traffic between signaling points may be routed via a packet switch called an STP. An STP routes each incoming message to an outgoing signaling link based on routing information contained in the SS7 message. Because it acts as a network hub, an STP provides improved utilization of the SS7 network by eliminating the need for direct links between signaling points. An STP may perform global title translation, a procedure by which the destination signaling point is determined from digits present in the signaling message (e.g., the dialed 800 number, calling card number, or mobile subscriber identification number). An STP can also act as a "firewall" to screen SS7 messages exchanged with other networks.
Because the SS7 network is critical to call processing, SCPs and STPs are usually deployed in mated pair configurations in separate physical locations to ensure network-wide service in the event of an isolated failure. Links between signaling points are also provisioned in pairs. Traffic is shared across all links in the linkset. If one of the links fails, the signaling traffic is rerouted over another link in the linkset. The SS7 protocol provides both error correction and retransmission capabilities to allow continued service in the event of signaling point or link failures.

•  Signaling gateways can be configured as an STP or SEP (Signaling End Point).

SS7 Signaling Link Types

Signaling links are logically organized by link type ("A" through "F") according to their use in the SS7 signaling network.

Figure 2. SS7 Signaling Link Types

A Link:	An "A" (access) link connects a signaling end point (e.g., an SCP or SSP) to an STP. Only messages originating from or destined to the signaling end point are transmitted on an "A" link.
B Link:	A "B" (bridge) link connects an STP to another STP. Typically, a quad of "B" links interconnect peer (or primary) STPs (e.g., the STPs from one network to the STPs of another network). The distinction between a "B" link and a "D" link is rather arbitrary. For this reason, such links may be referred to as "B/D" links.
C Link:	A "C" (cross) link connects STPs performing identical functions into a mated pair. A "C" link is used only when an STP has no other route available to a destination signaling point due to link failure(s). Note that SCPs may also be deployed in pairs to improve reliability; unlike STPs, however, mated SCPs are not interconnected by signaling links.
D Link:	A "D" (diagonal) link connects a secondary (e.g., local or regional) STP pair to a primary (e.g., inter-network gateway) STP pair in a quad-link configuration. Secondary STPs within the same network are connected via a quad of "D" links. The distinction between a "B" link and a "D" link is rather arbitrary. For this reason, such links may be referred to as "B/D" links.
E Link:	An "E" (extended) link connects an SSP to an alternate STP. "E" links provide an alternate signaling path if an SSP's "home" STP cannot be reached via an "A" link. "E" links are not usually provisioned unless the benefit of a marginally higher degree of reliability justifies the added expense.
F Link:	An "F" (fully associated) link connects two signaling end points (i.e., SSPs and SCPs). "F" links are not usually used in networks with STPs. In networks without STPs, "F" links directly connect signaling points.

Bluetooth 2 - Enhanced Data Rate, EDR

Bluetooth EDR or Bluetooth 2 is an upgrade of the original Bluetooth specification. It based on the original Bluetooth standard which is well established as a wireless technology. It has found a very significant number of applications, particularly in areas such as connecting mobile or cell phones to hands-free headsets.

One of the disadvantages of the original version of Bluetooth in some applications was that the data rate was not sufficiently high, especially when compared to other wireless technologies such as 802.11. In November 2004, a new version of Bluetooth, known as Bluetooth 2 was ratified. This not only gives an enhanced data rate but also offers other improvements as well.

Of all the features included in Bluetooth 2, it is the enhanced data rate (EDR), facility that is giving rise to the most comment. In the new specification the maximum data rate is able to reach 3 Mbps, a significant increase on what was available in the previous Bluetooth specifications.

Why is Bluetooth 2 needed?

As proved particularly by the computer industry, there is always a need for increased data rates, and ever increasing capacity. With this in mind and the fact that the previous version of Bluetooth, version 1.2 allowed a maximum data rate of 1 Mbps which reflected in a real throughput of 723 kbps, the next specification should allow many new applications to be run. In turn this will open up the market for Bluetooth even more and allow further application areas to be addressed.

While speed on its own opens up more opportunities, the strategy behind Bluetooth 2 with its enhanced data rate is more deep rooted. When the Bluetooth 2 specification was released there were no applications that were in immediate need of the new enhanced data rate. For example even a high quality stereo audio stream required a maximum of only 345 kbps.

The reason is that as Bluetooth use increases, and the number of applications increase, that users will need to run several links concurrently. Not only may Bluetooth need to be used for streaming audio, but other applications such as running computer peripherals will increase. The reason becomes clearer when looking at real situations when interference is present. Typically it is found that a good margin is required to allow for re-sends and other data. Under Bluetooth 1.2, high quality stereo audio can be sent on its own within the available bandwidth and with sufficient margin. However when other applications are added there is not sufficient margin to allow for the system to operate satisfactorily. Bluetooth 2 solves this problem and enables sufficient bandwidth for a variety of links to be operated simultaneously, while still allowing for sufficient bandwidth margin within the system.

There are other advantages to running Bluetooth 2. One of the major elements is in terms of power consumption. Although the transmitter and receiver and logic need to be able to handle data at a higher speed which normally requires a higher current consumption, this is more than outweighed by the fact that they need only to remain fully active for about a third of the time. This brings significant advantages in terms of battery life, a feature that is of particular important in many of the Bluetooth applications.

Compatibility is a major requirement when any system is upgraded. The same is true for Bluetooth, and this has been a major requirement and concern when developing the Bluetooth 2 standard. The new standard is completely backward compatible and allows networks to contain a mixture of EDR (enhanced data rate) devices as well as the standard devices. A key element of this is that the new modulation schemes that have been incorporated into Bluetooth 2 are compatible in their nature with the standard rate specification. In this way the new standard will be able to operate with any mixture of devices from whatever standard.

How it works

One of the main reasons why Bluetooth 2 is able to support a much higher data throughput is that it utilises a different modulation scheme for the payload data. However this is implemented in a manner in which compatibility with previous revisions of the Bluetooth standard is still retained.

Bluetooth data is transmitted as packets that are made up from a standard format. This consists of four elements which are: (a) The Access Code which is used by the receiving device to recognise the incoming transmission; (b) The Header which describes the packet type and its length; (c) The Payload which is the data that is required to be carried; and finally (d) The Inter-Packet Guard Band which is required between transmissions to ensure that transmissions from two sources do not collide, and to enable the receiver to re-tune.

In previous versions of the Bluetooth standard, all three elements of the transmission, i.e. Access Code, Header and Payload were transmitted using Gaussian Frequency Shift Keying (GFSK) where the carrier is shifted by +/- 160 kHz indicating a one or a zero, and in this way one bit is encoded per symbol.

The Bluetooth 2.0 specification uses a variety of forms of modulation. GFSK is still used for transmitting the Access Code and Header and in this way compatibility is maintained. However other forms of modulation can be used for the Payload. There are two additional forms of modulation that have been introduced. One of these is mandatory, while the other is optional.

A further small change is the addition of a small guard band between the Header and the payload. In addition to this a short synchronisation word is inserted at the beginning of the payload.

Mandatory modulation format

The first of the new modulation formats which must be included on any Bluetooth 2 device gives a two fold improvement in the data rate and thereby allows a maximum speed of 2 Mbps. This is achieved by using pi/4 differential quaternary phase shift keying (pi/4 DQPSK). This form of modulation is significantly different to the GFSK that was used on previous Bluetooth standards in that the new standard uses a form of phase modulation, whereas the previous ones used on frequency modulation.

Using quaternary phase shift modulation means that there are four possible phase positions for each symbol. Accordingly this means that two bits can be encoded per symbol, and this provides the two fold data increase over the frequency shift keying used for the previous versions of Bluetooth.

Higher speed modulation

To enable the full three fold increase in data rate to be achieved a further form of modulation is used. Eight phase differential phase shift keying (8DPSK) enables eight positions to be defined with 45 degrees between each of them. By using this form of modulation eight positions are possible and three bits can be encoded per symbol. This enables the data rate of 3 Mbps to be achieved.

As the separation between the different phase positions is much smaller than it was with the QPSK used to provide the two fold increase in speed, the noise immunity has been reduced in favour of the increased speed. Accordingly this optional form of modulation is only used when a link is sufficiently robust.

Packet formats

The Bluetooth 2 specification defines ten new packet formats for use with the higher data rate modulation schemes, five each for each of the enhanced data rate schemes. Three of these are for the 1, 3 and 5 slot asynchronous packets used for transferring data. The remaining two are used for 3 and 5 slot extended Synchronous Connection Orientated (eSCO) packets. These use bandwidth that is normally reserved for voice communications.

The new format for these packets does not incorporate FEC. If this is required then the system switches back automatically to the standard rate packets. However many of the links are over a very short range where the signal level is high and the link quality good.

It is necessary for the packet type to be identified so that the receiver can decode them correctly, knowing also the type of modulation being used. An identifier is therefore included in the header which is sent using GFSK. This packet header used for the previous version of Bluetooth only used 4 bits. This gave sufficient capability for the original system. However there was insufficient space for the additional information that needed to be sent for Bluetooth 2.

It was not possible to change the header format because backward compatibility would not be possible. Instead different link modes are defined. When two Bluetooth 2 or EDR devices communicate the messages are used in a slightly different way, indicating the Bluetooth 2 or EDR modes. In this way compatibility is retained while still being able to carry the required information.

Summary

Bluetooth 2 / EDR is a significant improvement to Bluetooth and will enable it to retain its position in the market place. Its introduction, as the Bluetooth has become more widely accepted and used will enable it to build on its position within the market place.

Bluetooth technology

This Bluetooth tutorial is split into several pages each of which addresses different aspects of Bluetooth operation and technology:

    [1] Bluetooth overview     [2] Bluetooth EDR

Bluetooth has now established itself in the market place enabling a variety of devices to be connected together using wireless technology. Bluetooth technology has come into its own connecting remote headsets to mobile phones, but it is also used in a huge number of other applications as well.

In fact Bluetooth technology is now an integral part of many household items. Cell phones and many other devices use Bluetooth for short range connectivity. In this sort of application, Bluetooth has been a significant success.

Bluetooth beginnings ...

Bluetooth technology originated in 1994 when Ericsson came up with a concept to use a wireless connection to connect items such as an earphone and a cordless headset and the mobile phone. The idea behind Bluetooth (it was not yet called Bluetooth) was developed further as the possibilities of interconnections with a variety of other peripherals such as computers printers, phones and more were realised. Using this technology, the possibility of quick and easy connections between electronic devices should be possible.

It was decided that in order to enable the technology to move forward and be accepted as an industry standard that it needed to be opened up as an industry standard. Accordingly, in Feb 1998, five companies (Ericsson, Nokia, IBM, Toshiba and Intel) formed a Special Interest Group (SIG). Three months later in May 1998, Bluetooth was publicly announced with the first specification following on with the first release of the standard in July 1999. Later more members were added to the group with four new companies, Motorola, Microsoft, Lucent and 3Com, joining the group. Since then more companies have joined and the specification has grown and is now used in a large variety of products.

The name

The name of the Bluetooth standard originates from the Danish king Harald Bl�tand who was king of Denmark between 940 and 981 AD. His name translates as "Blue Tooth" and this was used as his nickname. A brave warrior, his main achievement was that of uniting Denmark under the banner of Christianity, and then uniting it with Norway that he had conquered. The Bluetooth standard was named after him because Bluetooth endeavours to unite personal computing and telecommunications devices.

Bluetooth basics

Bluetooth is a wireless data system and can carry data at speeds up to 721 Kbps in its basic form and in addition to this it offers up to three voice channels. Bluetooth technology enables a user to replace cables between devices such as printers, fax machines, desktop computers and peripherals, and a host of other digital devices. Furthermore, it can provide a connection between an ad hoc wireless network and existing wired data networks.

The technology is intended to be placed in a low cost module that can be easily incorporated into electronics devices of all sorts. Bluetooth uses the licence free Industrial, Scientific and Medical (ISM) frequency band for its radio signals and enables communications to be established between devices up to a maximum distance of 100 metres.

RF system

Running in the 2.4 GHz ISM band, Bluetooth employs frequency hopping techniques with the carrier modulated using Gaussian Frequency Shift Keying (GFSK).

With many other users on the ISM band from microwave ovens to Wi-Fi, the hopping carrier enables interference to be avoided by Bluetooth devices. A Bluetooth transmission only remains on a given frequency for a short time, and if any interference is present the data will be re-sent later when the signal has changed to a different channel which is likely to be clear of other interfering signals. The standard uses a hopping rate of 1600 hops per second. These are spread over 79 fixed frequencies and they are chosen in a pseudo-random sequence. The fixed frequencies occur at 2400 + n MHz where the value of n varies from 1 to 79. This gives frequencies of 2402, 2404 �.. 2480 MHz. In some countries the ISM band allocation does not allow the full range of frequencies to be used. In France, Japan and Spain, the hop sequence has to be restricted to only 23 frequencies because of the ISM band allocation is smaller.

During the development of the Bluetooth standard it was decided to adopt the use of frequency hopping system rather than a direct sequence spread spectrum approach because it is able to operate over a greater dynamic range. If direct sequence spread spectrum techniques were used then other transmitters nearer to the receiver would block the required transmission if it is further away and weaker.

Modulation

The way in which the data is modulated onto the Bluetooth carrier was also carefully chosen. A form of frequency shift keying known as Gaussian Frequency Shift Keying is employed. Here the frequency of the carrier is shifted to carry the modulation. A binary one is represented by a positive frequency deviation and a binary zero is represented by a negative frequency deviation. It is then filtered using a filter with a Gaussian response curve to ensure the sidebands do not extend too far either side of the main carrier. By doing this it achieves a bandwidth of 1 MHz with stringent filter requirements to prevent interference on other channels. For correct operation the level of BT is set to 0.5 and the modulation index must be between 0.28 and 0.35.

Transmitter power levels

The transmitter powers for Bluetooth are quite low, although there are three different classes of output dependent upon the anticipated use and the range required. Power Class 1 is designed for long range communications up to about 100m devices, and this has a maximum output power of 20 dBm, Next is Power Class 2 which is used for what are termed for ordinary range devices with a range up to about 10m, with a maximum output power of 4 dBm. Finally there is Power Class 3 for short range devices. This support communication only to about 10cm and it has a maximum output power of 0 dBm.

There are also some frequency accuracy requirements for Bluetooth transmissions. The transmitted initial centre frequency must be within �75 kHz from the receiver centre frequency. The initial frequency accuracy is defined as being the frequency accuracy before any information is transmitted and as such any frequency drift requirement is not included.

In order to enable effective communications to take place in an environment where a number of devices may receive the signal, each device has its own identifier. This is provided by having a 48 bit hard wired address identity giving a total of 2.815 x 10^14 unique identifiers.

Data transfer

There are two ways in which data is transferred. The first is by using what is termed an Asynchronous Connectionless Communications Link (ACL). This is used for file and data transfers. A second method is termed a Synchronous Connection-orientated Communications Link (SCL). This is used for applications such as digital audio.

The ACL is enables data to be transferred via Bluetooth at speeds up to the maximum rate of 732.2 kbits/sec. This occurs when it is operating in an asymmetric mode. This is commonly used because for most applications there is far more data transferred in one direction than the other. When a symmetrical mode is needed with data transferred at the same rate in both directions, the data transfer rate falls to 433.9 kbits/sec. The synchronous links support two bi-directional connections at a rate of 64 kbits/sec. The data rates are adequate for audio and most file transfers. However the available data rate is insufficient for applications such as high rate DVDs that require 9.8 Mbit/sec or for many other video applications including games spectacles.

Data is organised into packets to be sent across a Bluetooth link. The Bluetooth specification lists seventeen different formats that can be used dependent upon the requirements. They have options for elements such as forward error correction data and the like. However the standard packet consists of a 72 bit access code filed, a 54 bit header field, and then the data to be transmitted which may be between 0 and 2745 bits. This data includes the 16 bit CRC if it is needed.

As it is likely that interference will cause errors, error handling is incorporated within the system. For asynchronous links packet sequence numbers are transmitted. If an error is detected in a packet then the receiver can request it to be re-sent. Error coding using a 16 bit CRC is also available. For the synchronous links packets cannot be re-sent as there is unlikely to be sufficient bandwidth available to re-send data and "catch up". However it is possible to include some forward error control.

Communication nets

In order that Bluetooth devices may communicate with each other they form small clusters or nets. These are termed "piconets" and comprise up to eight devices. Within a piconet, one of the devices assumes the role of "Master" while the others become slaves.

If more than eight devices are available to join the net, eight are allowed in, and the others need to remain in an inactive standby state. They may be requested to join the net at a later state if required.

To enable a net to eb set up, the master transmits an enquiry message every 1.28 seconds to discover whether there are any other devices within range. If a reply is received then an invitation to join the net is transmitted to the specific device that has responded. After this the master allocates each device a member address and then controls all the transmissions.

All Bluetooth devices have a clock that runs at twice the hopping speed and this provides synchronisation to the whole net. The master transmits in the even numbered time slots whilst the slaves transmit in the odd numbered slots once they have been given permission to transmit.

As security is becoming an important issue, especially where links to computers are concerned, secure communications are possible over Bluetooth with the devices encrypting the data transmitted. A key up to 128 bits is used and it is claimed that the level of security provided is sufficient for financial transactions. However in some countries the length of the key is limited to enable the security agencies to gain access if required.

Summary

Bluetooth is well established, but despite this further enhancements are being introduced. Faster data transfer rates, and greater flexibility. In addition to this efforts have been made to ensure that interoperation has been improved so that devices from different manufacturers can talk together more easily.

What is DVB-T?

DVB-T or Digital Video Broadcast - Terrestrial is the most widely used digital television standard in use around the globe for terrestrial television transmissions. It provides many facilities and enables a far more efficient use of the available radio frequency spectrum than the previous analogue transmissions.

The DVB-T standard was first published in 1997 and since then it has become the most widely used format for broadcast digital in the world. By 2008, it was the standard that was adopted in more than 35 countries and over 60 million receivers deployed and in use.

Major milestones in DVB-T development and deployment

• December 1994:   MPEG-2 ISO 13818-1 systems definition available
• July 1995:   demonstrations by BBC of digital terrestrial broadcasting to several UK government officials.
• January 1996:   The 4:2:2 video format standardised
• February 1996:   QAM-COFDM transmission system agreed for DVB-T
• 9th April 1996:   Implementation of the first phases of a digital terrestrial television pilot-service from Crystal Palace and Pontop Pike by BBC in the UK
• 24th December 1996:   U.S. Government adopts DTV as first step towards a U.S. digital terrestrial network
• March 1997:   First publication of the DVB-T stadnard
• December 1997:   Over 200 DVB Satellite TV channels live using DVB-T
• November 1998:   Transmission of DVB-T starts in the UK

DVB-T basics

DVB-T makes use of many modern technologies to enable it to deliver high quality video in a broadcast environment.

The DVB-T transmission is capable of carrying a very significant level of data. Normally several television broadcasts may be carried on a single transmission and in addition to this several audio channels may be carried as well. As a result each transmission is called a multiplex.

One of the key elements of the radio or air interface is the choice of the modulation scheme for DVB-T. In line with many other forms of transmission these days, DVB-T uses OFDM, Orthogonal Frequency Division Multiplex.

Note on OFDM:

Orthogonal Frequency Division Multiplex (OFDM) is a form of transmission that uses a large number of close spaced carriers that are modulated with low rate data. Normally these signals would be expected to interfere with each other, but by making the signals orthogonal to each another there is no mutual interference. This is achieved by having the carrier spacing equal to the reciprocal of the symbol period. This means that when the signals are demodulated they will have a whole number of cycles in the symbol period and their contribution will sum to zero - in other words there is no interference contribution. The data to be transmitted is split across all the carriers and this means that by using error correction techniques, if some of the carriers are lost due to multi-path effects, then the data can be reconstructed. Additionally having data carried at a low rate across all the carriers means that the effects of reflections and inter-symbol interference can be overcome. It also means that single frequency networks, where all transmitters can transmit on the same channel can be implemented.
Click on the link for an OFDM tutorial

In order that the DVB-T network is able to meet the requirements of the operator, it is possible to vary a number of the characteristics:

• 3 modulation options (QPSK, 16QAM, 64QAM):   There is a balance between the amount rate at which data can be transmitted and the signal to noise ratio that can be tolerated. The lower order modulation formats like QPSK do not transmit data as fast as the higher modulation formats such as 64QAM, but they can be received when signal strengths are lower.
• 5 different FEC (forward error correction) rates:   Any radio system transmitting data will suffer errors. In order to correct these errors various forms of error correction are used. The rate at which this is done affects the rate at which the data can be transmitted. The higher the level of error correction that is applied, the greater the level of supporting error correction data that needs to be transmitted. In turn this reduces the data rate of the transmission. Accordingly it is necessary to match the forward error correction level to the requirements of the broadcast network. The error correction uses convolutional coding and Reed Solomon with rates of 1/2, 2/3, 3/4, 5/6, and 7/8 dependent upon the requirements.
• 4 Guard Interval options:  
• 2k or 8k carriers:   According to the transmission requirements the number of carriers within the OFDM signal can be varied. When fewer carriers are used, each carrier must carry a higher bandwidth for the same overall multiplex data rate. This has an impact on the resilience to reflections and the spacing between transmitters in a single frequency network. Although the systems are labelled 2k and 8k the actual numbers of carriers used are 1705 carriers for the 2k service and 6817 carriers for the 8k service.
• 6, 7 or 8MHz channel bandwidths:   It is possible to tailor the bandwidth of the transmission to the bandwidth available and the channel separations. Three figures of bandwidth are available.
• Video at 50Hz or 60Hz:   The refresh rate for the a screen can be varied. Traditionally for analogue televisions this was linked to the frequency used for the local mains supplies.

By altering the various parameters of the transmission it is possible for network operators to find the right balance between the robustness of the DVB-T transmission and its capacity.

DVB-T single frequency network

One of the advantages of using OFDM as the form of modulation is that it allows the network to implement what is termed a single frequency network. A single frequency network, or SFN is one where a number of transmitters operate on the same frequency without causing interference.

many forms of transmission, including the old analogue television broadcasts would interfere with one another. Therefore when planning a network, adjacent areas could not use the same channels and this greatly increased the amount of spectrum required to cover a country. By using OFDM an SFN can be implemented and this provides a significant degree of spectrum efficiency improvement.

A further advantage of using a system such as DVB-T that uses OFDM and allows the implementation of an SFN is that very small transmitters can be used to enhance local coverage. Small "gap fillers" may even be used to enhance indoor coverage for DVB-T.

DVB-T hierarchical modulation

Another facility that is allowed by DVB-T is known as Hierarchical Modulation. Using this technique, two completely separate data streams can be modulated onto a single DVB-T signal. A "High Priority" or HP stream is embedded within a "Low Priority" or LP stream. Using this principle DVB-T broadcasters are able to target two different types of receiver with two completely different services.

One example where this could be used is for a DVB-H mobile TV service optimised for more difficult reception conditions could be placed in the HP stream, with HDTV DVB-T services targeted to fixed antennas delivered in the LP stream.

DVB-T specification highlights

Parameter	DVB-T
Number of carriers in signal	2k, 8k
Modulation formats	QPSK, 16QAM, 64 QAM
Scattered pilots	8% of total
Continual pilots	2.6% of total
Error correction	Convolutional Coding + Reed Solomon 1/2, 2/3, 3/4, 5/6, 7/8
Guard interval	1/4, 1/8, 1/16, 1/32

DVB-T summary

DVB-T is now well established. Many countries, including the UK are moving towards a complete switch-over from analogue to digital, with a resultant digital dividend releasing a significant amount of bandwidth for other services. However as DVB-T has now been in use for ten years a new standard, which is a development of the original DVB-T standard known as DVB-T2 is being developed. This would have backwards compatibility, but allow additional services and flexibility as well as a number of features to future-proof it.

Erlang and Erlang B Tutorial

The Erlang is widely used in telecommunications technology. The Erlang is a statistical measure of the voice traffic density in a telecommunications system and it is widely used because, for any element in a telecommunications system, whether it is a landline, or uses cellular technology, it is necessary to be able to understand the traffic volume. As a result it is helps to have a definition of the telecommunications traffic so that the volume can be quantified in a standard way and calculations can be made. Telecommunications network designers make great use of the Erlang to understand traffic patterns within a voice network and they use the figures to determine the capacity that is required in any area of the network.

Who was Erlang?

The Erlang is named after a Danish telephone engineer named A.K Erlang (Agner Krarup Erlang). He was born on 1st January 1878 and although he trained as a mathematician, he was the first person to investigate traffic and queuing theory in telephone circuits.

After receiving his MA, Erlang worked in a number of schools. However, Erlang was a member of the Danish Mathematician's Association (TBMI) and it was through this organization that Erlang met the Chief Engineer of the Copenhagen Telephone Company (CTC) and as a result, he went to work for them from 1908 for almost 20 years.

While he was at CTC, Erlang studied the loading on telephone circuits, looking at how many lines were required to provide an acceptable service without installing too much over-capacity that would cost the company money. There was a trade-off between cost and service level.

Erlang developed his theories over a number of years, and published several papers. He expressed his findings in mathematical forms so that they could be used to calculate the required level of capacity, and today the same basic equations are in widespread use..

In view of his groundbreaking work, the International Consultative Committee on Telephones and Telegraphs (CCITT) honoured him in 1946 by adopting the name "Erlang" for the basic unit of telephone traffic.

Erlang died on 3rd February 1929 after an unsuccessful abdominal operation.

Erlang basics

The Erlang is the basic unit of telecommunications traffic intensity representing continuous use of one circuit and it is given the symbol "E". It is effectively call intensity in call minutes per sixty minutes. In general the period of an hour is used, but it actually a dimensionless unit because the dimensions cancel out (i.e. minutes per minute).

The number of Erlangs is easy to deduce in a simple case. If a resource carries one Erlang, then this is equivalent to one continuous call over the period of an hour. Alternatively if two calls were in progress for fifty percent of the time, then this would also equal one Erlang (1E). Alternatively if a radio channel is used for fifty percent of the time carries a traffic level of half an Erlang (0.5E)

From this it can be seen that an Erlang, E, may be thought of as a use multiplier where 100% use is 1E, 200% is 2E, 50% use is 0.5E and so forth.

Interestingly for many years, AT&T and Bell Canada measured traffic in another unit called CCS, 100 call seconds. If figures in CCS are encountered then it is a simple conversion to change CCS to Erlangs. Simply divide the figure in CCS by 36 to obtain the figure in Erlangs

Erlang function or Erlang formula and symbol

It is possible to express the way in which the number of Erlangs are required in the format of a simple function or formula.

A     =     λ     x     h Where:
λ = the mean arrival rate of new calls
h = the mean call length or holding time
A = the traffic in Erlangs.

Using this simple Erlang function or Erlang formula, the traffic can easily be calculated.

Erlang-B and Erlang-C

Erlang calculations are further broken down as follows:

• Erlang B:   The Erlang B is used to work out how many lines are required from a knowledge of the traffic figure during the busiest hour. The Erlang B figure assumes that any blocked calls are cleared immediately. This is the most commonly used figure to be used in any telecommunications capacity calculations.
• Extended Erlang B:   The Extended Erlang B is similar to Erlang B, but it can be used to factor in the number of calls that are blocked and immediately tried again.
• Erlang C:   The Erlang C model assumes that not all calls may be handled immediately and some calls are queued until they can be handled.

These different models are described in further detail below.

Erlang B

It is particularly important to understand the traffic volumes at peak times of the day. Telecommunications traffic, like many other commodities, varies over the course of the day, and also the week. It is therefore necessary to understand the telecommunications traffic at the peak times of the day and to be able to determine the acceptable level of service required. The Erlang B figure is designed to handle the peak or busy periods and to determine the level of service required in these periods.

Erlang C

The Erlang C model is used by call centres to determine how many staff or call stations are needed, based on the number of calls per hour, the average duration of call and the length of time calls are left in the queue. The Erlang C figure is somewhat more difficult to determine because there are more interdependent variables. The Erlang C figure, is nevertheless very important to determine if a call centre is to be set up, as callers do not like being kept waiting interminably, as so often happens.

Erlang summary

The Erlang formulas and the concepts put forward by Erlang are still an essential part of telecommunications network planning these days. As a result, telecommunications engineers should have a good understanding of the Erlang and the associated formulae.

despite the widespread use of the Erlang concepts and formulae, it is necessary to remember that there are limitations to their use. It is necessary to remember that the Erlang formulas make assumptions. Erlang B assumes that callers who receive a busy tone will not immediately try again. Also Erlang C assumes that callers will not hold on indefinitely. It is also worth remembering that the Erlang formulas are based on statistics, and that to make these come true an infinite number of sources is required. However for most cases a total of ten sources gives an adequate number of sources to give sufficiently accurate results.

The Erlang is a particularly important element of telecommunications theory, and it is a cornerstone of many areas of telecommunications technology today. However one must be aware of its limitations and apply the findings of any work using Erlangs, the Erlang B and Erlang C formulas or functions with a certain amount of practical knowledge.

Satellite communications basics

Satellites are able fulfill a number of roles. One of the major roles is for satellite communications. Here the satellite enables communications to be established over large distances - well beyond the line of sight. Communications satellites may be used for many applications including relaying telephone calls, providing communications to remote areas of the Earth, providing satellite communications to ships, aircraft and other mobile vehicles, and there are many more ways in which communications satellites can be used.

Satellite communications basics

When used for communications, a satellite acts as a repeater. Its height above the Earth means that signals can be transmitted over distances that are very much greater than the line of sight. An earth station transmits the signal up to the satellite. This is called the up-link and is transmitted on one frequency. The satellite receives the signal and retransmits it on what is termed the down link which is on another frequency.

Using a satellite for long distance communications

The circuitry in the satellite that acts as the receiver, frequency changer, and transmitter is called a transponder. This basically consists of a low noise amplifier, a frequency changer consisting a mixer and local oscillator, and then a high power amplifier. The filter on the input is used to make sure that any out of band signals such as the transponder output are reduced to acceptable levels so that the amplifier is not overloaded. Similarly the output from the amplifiers is filtered to make sure that spurious signals are reduced to acceptable levels. Figures used in here are the same as those mentioned earlier, and are only given as an example. The signal is received and amplified to a suitable level. It is then applied to the mixer to change the frequency in the same way that occurs in a superheterodyne radio receiver. As a result the communications satellite receives in one band of frequencies and transmits in another.

In view of the fact that the receiver and transmitter are operating at the same time and in close proximity, care has to be taken in the design of the satellite that the transmitter does not interfere with the receiver. This might result from spurious signals arising from the transmitter, or the receiver may become de-sensitised by the strong signal being received from the transmitter. The filters already mentioned are used to reduce these effects.

Block diagram of a basic satellite transponder

Signals transmitted to satellites usually consist of a large number of signals multiplexed onto a main transmission. In this way one transmission from the ground can carry a large number of telephone circuits or even a number of television signals. This approach is operationally far more effective than having a large number of individual transmitters.

Obviously one satellite will be unable to carry all the traffic across the Atlantic. Further capacity can be achieved using several satellites on different bands, or by physically separating them apart from one another. In this way the beamwidth of the antenna can be used to distinguish between different satellites. Normally antennas with very high gains are used, and these have very narrow beamwidths, allowing satellites to be separated by just a few degrees.

Separating satellites by position

Telecommunications satellite links

Communications satellites are ideally placed to provide telecommunications links between different places across the globe. Traditional telecommunications links used direct "cables" linking different areas. As a result of the cost of installation and maintenance of these cables, satellites were seen as an ideal alternative. While still expensive to put in place, they provided a high bandwidth and were able to operate for many years.

In recent years the bandwidth that can be offered by cables has increased considerably, and this has negated some of the gains of satellites. Additionally the geostationary satellites used for telecommunications links introduce a significant time delay in view of the very large distances involved. This can be a problem for normal telephone calls.

Mobile satellite communications systems

There are many instances where communications need to be maintained over wide areas of the globe. Ships, aircraft and the like, need to be able to communicate from points all around the world. Traditionally HF radio communications ahs been used, but this is unreliable. Satellite communications provide an ideal solution to this problem as satellite communications are much more reliable and they are able to provide interference free stable communications links. As a result, Satellite communications is now fitted as standard to all maritime vessels, and it is becoming increasingly used by aircraft, although it is not yet adopted for Air Traffic management (ATM).

In addition to these users, these services can be sued by many land mobile or land portable radio users. Satellite terminals provide are able to access the satellite and the users is able to achieve communications from almost anywhere on the globe. As these communications satellites are in geostationary orbits, communications is not possible towards the poles as in these regions it is not possible to see the satellites.

Direct broadcast communications satellites

Another variant of communications satellites is those used for direct broadcasting. This form of broadcasting has become very popular as it provides very high levels of bandwidth because of the high frequencies used. This means that large numbers of channels can be carried. It also enables large areas of the globe to be covered by one delivery system. For terrestrial broadcasting a large number of high power transmitters are required that are located around the country. Even then coverage may not be good in outlying areas.

These DBS satellites are very similar to ordinary communications satellites in concept. Naturally they require high levels of transmitted power because domestic users do not want very large antennas on their houses to be able to receive the signals. This means that very large arrays of solar cells are required along with large batteries to support the broadcasting in periods of darkness. They also have a number of antenna systems accurately directing the transmitted power to the required areas. Different antennas on the same satellite may have totally different footprints.

Satellite phone systems

Satellites have also been used for cellular style communications. They have not been nearly as successful as initially anticipated because of the enormously rapid growth of terrestrial cellular telecommunications, and its spread into far more countries and areas than predicted when the ideas for satellite personal communications was originally envisaged. Nevertheless these satellite phone systems are now well established and have established a specific market. Accordingly these satellite phone systems are now widely available for mobile communications over wide areas of the globe.

The satellite phone systems that are available have varying degrees of coverage. Some provide true global coverage, although others are restricted to the more densely populated areas of the globe.

The systems that were set up used low earth orbiting satellites, typically with a constellation of around 66 satellites. Handheld phones then communicated directly with the satellites which would then process and relay the signals as required.

Other satellite phone systems use a number of geostationary satellites, although these satellite phone systems generally require the use of a directional antenna in view of the larger distances that need to be covered to and from the satellite. Additionally the levels of latency are higher (i.e. time delay for the signal to travel to and from the satellite) in view of the much higher orbit required. However as the satellites are geostationary, satellite or beam handover is less of a problem.

The main advantage of the satellite system is that it is truly global and communications can be made from ships, in remote locations where there would be no possibility of there being a communications network. However against this the network is expensive to run because of the cost of building and maintaining the satellite network, as well as the more sophisticated and higher power handsets required to operate with the satellite. As a result calls are more expensive than those made over terrestrial mobile phone networks.

Satellite communications summary

Although the basics of satellite communications are fairly straightforward, there is a huge investment required in building the satellite and launching it into orbit. Nevertheless many communications satellites exist in orbit around the globe and they are widely used for a variety of applications from providing satellite telecommunications links to direct broadcasting and the use of satellite phone and individual satellite communication links.