Telecommunication Network

PCM 30

noreply@blogger.com (Secred Admirer) — Sun, 28 Mar 2010 08:37:00 +0000

PCM30 describes an application of pulse-code modulation (PCM) in which 30 telephony analog signals are binary coded into a digital signal stream.

The term is used today mostly as a synonym for the encoding of 30 channels each with a signalling rate of 64-kbit/s. This rate is also used in the first stage of European PDH technique, so PCM30 is also known as E1.

Originally it described a device in communications technology which converted the 30 analog telephone signals into a digital bit stream of 2048 kbit/s .

PCM30 system

The PCM30-base system, the analog switching technology in Europe, and served on the digital transmission of telephone traffic. It has 30 coders, each with a phone channel in an 8-bit digital word (byte) can implement. The 30 bytes are, together with a frame ID word, and a channel identifier, bytewise successively sent #Multiplexer#. Thus, a large 32-byte frame. In receiving direction, the 30 channels are, using a de-multiplexer, converted back to 30 analogue signals. The time slot 0 is used as a frame ID word, and as word detection is used. These are sent alternately. Time slot 16 is a channel identifier for the speech channels. Each voice channel is assigned 4 bits, one after the other in 16 frame are sent, there is an over-under with a frequency of 500 Hz and a length of 16 ⋅ 32 ⋅ 8 # 4096 bits.

Operation summery

The analog input signals are initially passed through a low-pass filter. Then, the signals from the multiplexer are cyclically sampled at a frequency of 8 kHz. There is a PAM signal all injected signals. This is after the A-curve hörgerecht quantized by an analogue to digital (A/D) converter as 8-bit binary word coded. Since 8000 samples each second, each with 8 bits to be made is that each bit stream at 64 kbit/s. The sum of all 32 channels #30 channels + 2 telephone management channels# the bit rate of 2048 kbit/s.

For the transmission is still not suitable binary signal. Conducted DC transmission requires freedom and constant synchronous information. The binary bit stream is therefore on the intermediate stage of the AMI code in the HDB3 code umcodiert. The entire bit stream of 32 Fernsprechkanälen is HDB3 encoded with 2.048 Mbit/s on the distant opposite body. Distances> 3.5 km with regenerators, the so-called Line equipment bridges.

Since 2005 in Germany but no PCM30 lines on HDB3 base provided. Instead, the 2B1Q - encoding used by the baud rate #Vs# at a constant transmission rate #VUE# in half and allows the signal to a lower frequency band to relocate. This in turn has a positive effect on the attenuation of the signal and its range.

Specification of PCM30 system

Number of channels #time slots#: 32
Fernsprechkanäle Number: 30
Frame duration: 125 microseconds
Channel length: 3.9 microseconds
Kanalbitzahl: 8 bit
Bit duration: 0.488 ms
Bitrate: 2048 kbit / s #2.048 Mbit / s#
Bit rate per channel: 64 kbit/s
Clock frequency: 8 kHzrame bits)

SS7 "Clasic" vs SS7 over IP

noreply@blogger.com (Secred Admirer) — Sun, 28 Mar 2010 08:26:00 +0000

SS7 "Classic"

The term SS7 classic differentiates between SS7 over IP and narrowband 64-kilobit SS7. SS7 classic is signaling for call delivery that follows a separate physical path from the bearer channel to set up calls. A Service Switching Point (SSP) communicates to another SSP, with media traffic fl owing through on a separate channel from the signaling. Service Control Points (SCP) provide services that can be delivered via signaling alone (e.g., 800 service). Service Nodes (SN) and Intelligent Peripherals can be used for delivering services that require both signaling interaction and interaction with the bearer. Voice mail, follow-me services, and prepaid service are typical SN applications. Figure 1 represents the classical Intelligent Network (IN) environment, with the ability to deploy service on SCPs and SNs/ Intelligent Peripherals.

Figure 1: SS7 “Classic”

Evolution to SS7 over IP

The Internet Engineering Task Force (IETF) is driving much of the activity to develop protocols for the evolution of SS7 to SS7 over IP. The Signaling Transport (SIGTRAN) working group is focusing on how the existing SS7 protocol will run over IP.

One approach is to attempt to enable the SS7 service levels to run over IP. The fi rst step is creating components - such as Simple Control Transport Protocol (SCTP) - to run directly over IP, thus replacing Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) to provide a reliable transport for signaling in the telephony networks.

In addition, adaptation layers adapt the generic SCTP transport capability to meet the needs of various SS7 protocols. In the case of Message Transport Protocol 2 (MTP2) peer-to-peer adaptation (M2PA), the adaptation layer adapts the SCTP generic transport to enable Message Transfer Part 3 (MTP3) to run over it. As a result, an existing SS7 link can run directly over IP with all the existing services remaining the same.

Message Transfer Protocol 3-User Adaptation layer (M3UA) is an adaptation layer that adapts the SCTP to the MTP3 boundary. Consequently, Integrated Services Digital Network User Part (ISUP) and Signaling Connection Control Part (SCCP) can run directly over IP without having to adopt an SS7 link-based topology. While M2PA requires the maintenance of the topology of SS7 and SS7 links, M3UA requires only SS7 endpoints, thus participating at only the services level rather than needing the SS7 topology.

Another evolving adaptation layer is SCCP User Adaptation Layer (SUA). Although not as mature as some of the other adaptation layers, SUA is a protocol evolving to allow Transactional Capabilities Application Part (TCAP) to run on top of SCTP. TCAP can run on top of M3UA as well, but SUA is slightly lighter weight than M3UA and SCCP as an endpoint (see Figure 2).

Figure 2: Evolution to SS7 over IP

source: http://www.ulticom.com/

SS7 Signaling in PSTN

noreply@blogger.com (Secred Admirer) — Sun, 28 Mar 2010 08:02:00 +0000

Signaling in Switched Circuit Networks

Switched circuit telephone networks use a signaling protocol called Common Channel Signaling System 7 (more commonly called SS7 or C7). For more information, refer to the SS7 tutorial on this site. In the public switched telephone network, signaling end points send and receive SS7 signaling messages. There are three kinds of signaling end points (see diagram below):

Service Switching Point (SSP or central office switch)
Signal Transfer Point (STP)
Service Control Point (SCP)

In SS7 networks, ISUP (Integrated Services Digital Network (ISDN) User Part) signaling messages are used to setup, manage and release trunk circuits that carry voice calls between central office switches. ISUP messages also carry caller ID information, such as the calling party's telephone number and name. ISUP is used for both ISDN and non-ISDN calls between central office switches.

TCAP (Transaction Capabilities Application Part) signaling messages support telephony services, such as toll-free (freephone), calling card, local number portability and mobile (wireless) roaming and authentication services. Mobile services are enabled by information carried in the Mobile Application Part (MAP) of a TCAP message. TCAP supports non-circuit related information exchange between signaling points using the Signaling Connection Control Part (SCCP) connectionless service.

SS7 Signaling end points in a switched circuit network

Signaling in VoIP Networks

VoIP networks carry SS7-over-IP using protocols defined by Signaling Transport (sigtran) working group of the Internet Engineering Task Force (IETF), the international organization responsible for recommending Internet standards. The sigtran protocols support the stringent requirements for SS7/C7 signaling as defined by International Telecommunication Union (ITU) Telecommunication Standardization Sector.

In IP telephony networks, signaling information is exchanged between the following functional elements:

Media Gateway: A media gateway terminates voice calls on inter-switch trunks from the public switched telephone network, compresses and packetizes the voice data, and delivers compressed voice packets to the IP network. For voice calls originating in an IP network, the media gateway performs these functions in reverse order. For ISDN calls from the PSTN, Q.931 signaling information is transported from the media gateway to the media gateway controller (described below) for call processing.
Media Gateway Controller: A media gateway controller handles the registration and management of resources at the media gateway(s). A media gateway controller exchanges ISUP messages with central office switches via a signaling gateway (described below). Because vendors of media gateway controllers often use off-the-shelf computer platforms, a media gateway controller is sometimes called a softswitch.
Signaling Gateway: A signaling gateway provides transparent interworking of signaling between switched circuit and IP networks. The signaling gateway may terminate SS7 signaling or translate and relay messages over an IP network to a media gateway controller or another signaling gateway. Because of its critical role in integrated voice networks, signaling gateways are often deployed in groups of two or more to ensure high availability.

A media gateway, signaling gateway or media gateway controller (softswitch) may be separate physical devices or integrated in any combination.

Example of a VoIP network configuration

Sigtran Protocols

The sigtran protocols specify the means by which SS7 messages can be reliably transported over IP networks. The architecture identifies two components: a common transport protocol for the SS7 protocol layer being carried and an adaptation module to emulate lower layers of the protocol. For example, if the native protocol is MTP (Message Transport Layer) Level 3, the sigtran protocols provide the equivalent functionality of MTP Level 2. If the native protocol is ISUP or SCCP, the sigtran protocols provide the same functionality as MTP Levels 2 and 3. If the native protocol is TCAP, the sigtran protocols provide the functionality of SCCP (connectionless classes) and MTP Levels 2 and 3.

The sigtran protocols provide all functionality needed to support SS7 signaling over IP networks, including:

flow control
in-sequence delivery of signaling messages within a single control stream
identification of the originating and terminating signaling points
identification of voice circuits
error detection, retransmission and other error correcting procedures
recovery from outages of components in the transit path
controls to avoid congestion on the Internet
detection of the status of peer entities (e.g., in service, out-of-service, etc.)
support for security mechanisms to protect the integrity of the signaling information
extensions to support security and future requirements

Restrictions imposed by narrowband SS7 networks, such as the need to segment and reassemble messages greater than 272 bytes, are not applicable to IP networks and therefore not supported by the sigtran protocols.
Performance Considerations for SS7 over IP

SS7 messages transported over IP networks must meet the stringent performance requirements imposed by both the ITU SS7/C7 standards and user expectations. For example, while the ITU standard specifies that the end-to-end call setup delay cannot exceed 20 to 30 seconds after the ISUP Initial Address Message (IAM) is transmitted, users have generally come to expect much faster response times. For this reason, VoIP networks must be engineered to satisfy user expectations and ITU standards for performance.
Security Requirements for SS7 over IP

If signaling messages are transported over a private intranet, security measures can be applied as deemed necessary by the network operator. For signaling messages transported over the public Internet, the use of security measures is mandatory.

Several security mechanisms are currently available for use in IP networks. For transmission of signaling information over the Internet, sigtran recommends the use of IPSEC (see RFC2401). IPSEC provides the following security services:

Authentication: to ensure information is sent to/from a known and trusted partner
Integrity: to ensure that the signaling information has not been modified in-transit
Confidentiality: to ensure that the transported information is encrypted to avoid illegal use or violation of privacy laws
Availability: to ensure communicating endpoints under attack remain in service for authorized use

The sigtran protocols do not define new security mechanisms as the currently available security protocols provide the necessary mechanisms for secure transmission of SS7 messages over IP networks.

SS7 Layer

noreply@blogger.com (Secred Admirer) — Sun, 28 Mar 2010 07:37:00 +0000

BICC
Bearer Independent Call Control protocol is a call control protocol used between serving nodes. This protocol is based on the ISUP protocol, and was adapted to support the ISDN services independent of the bearer technology and signalling message transport technology used.

BISUP
The B-ISDN User Part (B-ISUP) is applicable to international B-ISDN networks. In addition, the B-ISDN User Part is suitable for national applications. Most messages and parameters specified for international use are also required in typical national applications. Moreover, coding space has been reserved in order to allow national administrations and recognized operating agencies to introduce network specific signalling messages and parameters within the internationally standardized protocol structure.

DUP
The Data User Part (DUP) defines the necessary call control, and facility registration and cancellation related elements for international common channel signalling by use of Signalling System No. 7 for circuit-switched data transmission services. The data signalling messages are divided into two categories:

Call and circuit related messages: used to set up and clear a call or control and supervise the circuit state.
Facility registration and cancellation related messages: used to exchange information between originating and destination exchanges to register and cancel information related to user facilities.

ISUP
ISUP is the ISDN User Part of SS7. ISUP defines the protocol and procedures used to setup, manage and release trunk circuits that carry voice and data calls over the public switched telephone network. ISUP is used for both ISDN and non-ISDN calls. Calls that originate and terminate at the same switch do not use ISUP signalling. ISDN User Part messages are carried on the signalling link by means of signal units. The signalling information field of each message signal unit contains an ISDN User Part message consisting of an integral number of octets.

MAP
Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming are carried by TCAP In mobile networks (IS-41 and GSM) when a mobile subscriber roams into a new mobile switching center (MSC) area, the integrated visitor location register requests service profile information from the subscriber's home location register (HLR) using MAP (mobile application part) information carried within TCAP messages.

MTP-2
Message Transfer Part - Level 2 (MTP-2) is a signalling link which together with MTP-3 provides reliable transfer of signalling messages between two directly connected signalling points.

MTP-3
Message Transfer Part - Level 3 (MTP-3) connects Q.SAAL to the users. It transfers messages between the nodes of the signalling network. MTP-3 ensures reliable transfer of the signalling messages, even in the case of the failure of the signalling links and signalling transfer points. The protocol therefore includes the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and appropriately reconfigure the routing of messages through the signalling network.

Q2140
The SSCF for NNI Signaling standard consists of the Service Specific Coordination Function (SSCF) in conjunction with the Service Specific Connection Oriented Protocol (SSCOP) which defines the Service Specific Convergence Sublayer (SSCS). The purpose of the Service Specific Coordination Function is to enhance the services of SSCOP to meet the needs of the requirements of the NNI level 3 protocol. In addition the SSCF at the NNI provides communication with Layer Management for proper operation of signalling links.
The SSCF at the NNI is the uppermost sub-layer in the protocol stack for the SAAL at the NNI. By construction, it utilizes the services of the underlying SAAL sub-layers, in combination with its own functions, to provide an overall SAAL service to the SAAL user, as described below.
The SAAL at the NNI provides signalling link functions for the transfer of signalling messages over one individual signalling data link. The SAAL functions provide a signalling link for reliable transfer of signalling messages between two signalling points.
A signalling message delivered by the higher levels is transferred over the signalling link in variable length Protocol Data Units (PDUs). For proper operation of the signalling link, the PDU comprises transfer control information in addition to the information content of the signalling message.

SCCP
The Signalling Connection Control Part (SCCP) offers enhancements to MTP level 3 to provide connectionless and connection-oriented network services, as well as to address translation capabilities. The SCCP enhancements to MTP provide a network service which is equivalent to the OSI Network layer 3.

TCAP
TCAP (Transaction Capabilities Application Part) enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signalling points using the SCCP connectionless service. TCAP messages are contained within the SCCP portion of an MSU. A TCAP message is comprised of a transaction portion and a component portion.
A TCAP message is structured as a single constructor information element consisting of the following: Transaction Portion, which contains information elements used by the Transaction sub-layer; a Component Portion, which contains information elements used by the Component sub-layer related to components; and, optionally, the Dialogue Portion, which contains the Application Context and user information, which are not components. Each Component is a constructor information element.

TUP
The Telephone User Part (TUP) carries the telephone user messages on the signalling data link by means of signal units.
The signalling information of each message constitutes the signalling information field of the corresponding signal unit and consists of an integral number of octets. It basically contains the label, the heading code and one or more signals and/or indications.
The service information octet comprises the service indicator and the subservice field.
The service indicator is used to associate signalling information with a particular User Part and is only used with message signal units (see Recommendation Q.704, § 12.2).
The information in the subservice field permits a distinction to be made between national and international signalling messages. In national applications when this discrimination is not required possibly for certain national User Parts only, the subservice field can be used independently for different User Parts.

SIGTRAN

noreply@blogger.com (Secred Admirer) — Sun, 28 Mar 2010 06:46:00 +0000

SIGTRAN is the name, derived from signaling transport, of a defunct Internet Engineering Task Force (IETF) working group that produced specifications for a family of protocols that provide reliable datagram service and user layer adaptations for Signaling System 7 (SS7) and ISDN communications protocols. The SIGTRAN protocols are an extension of the SS7 protocol family. It supports the same application and call management paradigms as SS7 but uses an Internet Protocol (IP) transport called Stream Control Transmission Protocol (SCTP). Indeed, the most significant protocol defined by the SIGTRAN group is SCTP, which is used to carry PSTN signaling over IP.
The SIGTRAN group was significantly influenced by telecommunications engineers intent on using the new protocols for adapting VoIP networks to the PSTN with special regard to signaling applications. Recently, SCTP is finding applications beyond its original purpose wherever reliable datagram service is desired.
SIGTRAN has been published in RFC 2719, under the title Architectural Framework for Signaling Transport. RFC 2719 also defines the concept of a Signaling gateway (SG), which converts CCS messages from SS7 to SIGTRAN. Implemented in a variety of network elements including softswitches, the SG function can provide significant value to existing common channel signaling networks, leveraging investments associated with SS7 and delivering the cost/performance values associated with IP transport.

SIGTRAN protocols

The SIGTRAN family of protocols includes:

Mapping

Status of ASPs

SCTP Stream Management

Seamless Network Management Interworking

Congestion Management

M2PA (MTP2-User Peer-to-Peer Adaptation Layer)

A Signaling Gateway (SG) and a Media Gateway Controller (MGC)
A SG and an IP Signaling Point (IPSP)
An IPSP and an IPSP

Seamless operation of MTP3 protocol peers over an IP network connection.
The MTP Level 2 / MTP Level 3 interface boundary.
Management of SCTP transport associations and traffic instead of MTP2 Links.
Asynchronous reporting of status changes to management.

M2UA

M3UA

SCTP

Acknowledged error-free non-duplicated transfer of user data.
Application-level segmentation to conform to discovered MTU size.
Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams.
Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
Enhanced reliability through support of multi-homing at either or both ends of the association.

Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP, RANAP etc.).
Support for SCCP connectionless service.
Support for SCCP connection oriented service.
Support for the seamless operation of SCCP-User protocol peers
Support for the management of SCTP transport associations between a SG and one or more IP-based signaling nodes).
Support for distributed IP-based signaling nodes.
Support for the asynchronous reporting of status changes to management The protocol is modular in design, allowing different implementations to be made, based upon the environment that needs to be supported. Depending upon the upper layer protocol supported, the SUA will need to support SCCP connectionless service, SCCP connect- orient service or both services.

V5UA

ftp://ftp:rfc-editor.org/iin-notes/rfc3807.txt

There is a need for Switched Circuit Network (SCN) signaling protocol delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway Controller (MGC), analogous to the implementation of the ISDN Q.921 User Adaptation Layer (IUA).

Since the V5.2 Layer 2, and especially Layer 3, differs from the Q.921 and Q.931 Adaptation layer, the IUA standard must be extended to fulfil the needs for supporting V5.2.

V5.2 is an industry standard ETSI interface (reference ETS 300 347-1) defined between a Local Exchange (LE) and an Access Network (AN) providing access to the following types:

Analog telephone access.
ISDN Basic rate access.
ISDN Primary Rate access.
Other analog or digital accesses for semi-permanent connections without associated outband signaling information.

Extending IUAP to V5UA to support V5.2 backhaul requires the introduction of new boundary primitives for the Q.921/Q.931 boundary, in accordance with the definitions in the V5 standards.

V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA primitive is used for transport of both V5 Layer 3 messages and V5 ISDN Layer 3 messages. The DL-UNIT DATA primitive is only used for V5 ISDN messages and is used and defined as described for IUAP.

Header

Version

Contains the version of the V5UA adaptation layer. The supported version is 1 (Release 1.0).

Message Classes and Types

The following List contains the valid Message Classes:

Message Class:

0

Management (MGMT) Message

3

ASP State Maintenance (ASPSM) Messages

4

ASP Traffic Maintenance (ASPTM) Messages

9

V5 Boundary Primitives Transport Messages (V5PTM)

The message names for the defined messages are as follows:

Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 TEI Status Request
3 TEI Status Confirm
4 TEI Status Indication
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions

Application Server Process State Maintenance (ASPSM) messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heatbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions

Application Server Process Traffic Maintenance (ASPTM) messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions

V5 Boundary Primitives Transport Messages (V5PTM)
1 Data Request Message (MGC -> SG)
2 Data Indication Message (SG -> MGC)
3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC)
11 Link Status Start Reporting (MGC -> SG)
12 Link Status Stop Reporting (MGC -> SG)
13 Link Status Indication (SG -> MGC)
14 Sa-Bit Set Request (MGC -> SG)
15 Sa-Bit Set Confirm (SG -> MGC)
16 Sa-Bit Status Request (MGC -> SG)
17 Sa-Bit Status Indication (SG -> MGC)
18 Error Indication (SG -> MGC)

ZigBee 802.15.4

noreply@blogger.com (Secred Admirer) — Sun, 28 Feb 2010 01:07:00 +0000

ZigBee is a specification for a suite of high level communication protocols using small, low-power digital radios based on the IEEE 802.15.4-2003 standard for wireless personal area networks (WPANs), such as wireless headphones connecting with cell phones via short-range radio. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs, such as Bluetooth. ZigBee is targeted at radio-frequency (RF) applications that require a low data rate, long battery life, and secure networking.

The ZigBee Alliance is a group of companies that maintain and publish the ZigBee standard.

Overview
ZigBee is a low-cost, low-power, wireless mesh networking proprietary standard. The low cost allows the technology to be widely deployed in wireless control and monitoring applications, the low power-usage allows longer life with smaller batteries, and the mesh networking provides high reliability and larger range.

The ZigBee Alliance, the standards body that defines ZigBee, also publishes application profiles that allow multiple OEM vendors to create interoperable products. The current list of application profiles either published or in the works are:

Home Automation
ZigBee Smart Energy
Commercial Building Automation
Telecommunication Applications
Personal, Home, and Hospital Care
Toys

The relationship between IEEE 802.15.4 and ZigBee is similar to that between IEEE 802.11 and the Wi-Fi Alliance. The ZigBee 1.0 specification was ratified on 14 December 2004 and is available to members of the ZigBee Alliance. Most recently, the ZigBee 2007 specification was posted on 30 October 2007. The first ZigBee Application Profile, Home Automation, was announced 2 November 2007.

ZigBee operates in the industrial, scientific and medical (ISM) radio bands; 868 MHz in Europe, 915 MHz in the USA and Australia, and 2.4 GHz in most jurisdictions worldwide. The technology is intended to be simpler and less expensive than other WPANs such as Bluetooth. ZigBee chip vendors typically sell integrated radios and microcontrollers with between 60K and 128K flash memory, such as the Jennic JN5148, the Freescale MC13213, the Ember EM250, the Texas Instruments CC2430, the Samsung Electro-Mechanics ZBS240 and the Atmel ATmega128RFA1. Radios are also available stand-alone to be used with any processor or microcontroller. Generally, the chip vendors also offer the ZigBee software stack, although independent ones are also available.

Because ZigBee can activate (go from sleep to active mode) in 15 msec or less, the latency can be very low and devices can be very responsive — particularly compared to Bluetooth wake-up delays, which are typically around three seconds. Because ZigBees can sleep most of the time, average power consumption can be very low, resulting in long battery life.

The first stack release is now called ZigBee 2004. The second stack release is called ZigBee 2006, and mainly replaces the MSG/KVP structure used in 2004 with a "cluster library". The 2004 stack is now more or less obsolete.

ZigBee 2007, now the current stack release, contains two stack profiles, stack profile 1 (simply called ZigBee), for home and light commercial use, and stack profile 2 (called ZigBee Pro). ZigBee Pro offers more features, such as multi-casting, many-to-one routing and high security with Symmetric-Key Key Exchange (SKKE), while ZigBee (stack profile 1) offers a smaller footprint in RAM and flash. Both offer full mesh networking and work with all ZigBee application profiles.

ZigBee 2007 is fully backward compatible with ZigBee 2006 devices: A ZigBee 2007 device may join and operate on a ZigBee 2006 network and vice versa. Due to differences in routing options, ZigBee Pro devices must become non-routing ZigBee End-Devices (ZEDs) on a ZigBee 2006 or ZigBee 2007 network, the same as ZigBee 2006 or ZigBee 2007 devices must become ZEDs on a ZigBee Pro network. The applications running on those devices work the same, regardless of the stack profile beneath them.

Licensing
For non-commercial purposes, the ZigBee specification is available free to the general public. An entry level membership in the ZigBee Alliance, called Adopter, provides access to the as-yet unpublished specifications and permission to create products for market using the specifications.

The click through license on the ZigBee specification requires a commercial developer to join the ZigBee Alliance. "No part of this specification may be used in development of a product for sale without becoming a member of ZigBee Alliance." The annual fee conflicts with the GNU General Public License. From the GPL v2, "b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." Since the GPL makes no distinction between commercial and non-commercial use it is impossible to implement a GPL licensed ZigBee stack or combine a ZigBee implementation with GPL licensed code. The requirement for the developer to join the ZigBee Alliance similarly conflicts with most other Free software licenses.

Uses
ZigBee protocols are intended for use in embedded applications requiring low data rates and low power consumption. ZigBee's current focus is to define a general-purpose, inexpensive, self-organizing mesh network that can be used for industrial control, embedded sensing, medical data collection, smoke and intruder warning, building automation, home automation, etc. The resulting network will use very small amounts of power — individual devices must have a battery life of at least two years to pass ZigBee certification.

Typical application areas include

Home Entertainment and Control — Smart lighting, advanced temperature control, safety and security, movies and music
Home Awareness — Water sensors, power sensors, energy monitoring, smoke and fire detectors, smart appliances and access sensors
Mobile Services — m-payment, m-monitoring and control, m-security and access control, m-healthcare and tele-assist
Commercial Building — Energy monitoring, HVAC, lighting, access control
Industrial Plant — Process control, asset management, environmental management, energy management, industrial device control

Device types
There are three different types of ZigBee devices:

ZigBee coordinator (ZC): The most capable device, the coordinator forms the root of the network tree and might bridge to other networks. There is exactly one ZigBee coordinator in each network since it is the device that started the network originally. It is able to store information about the network, including acting as the Trust Centre & repository for security keys.
ZigBee Router (ZR): As well as running an application function, a router can act as an intermediate router, passing on data from other devices.
ZigBee End Device (ZED): Contains just enough functionality to talk to the parent node (either the coordinator or a router); it cannot relay data from other devices. This relationship allows the node to be asleep a significant amount of the time thereby giving long battery life. A ZED requires the least amount of memory, and therefore can be less expensive to manufacture than a ZR or ZC.

Protocols
The protocols build on recent algorithmic research (Ad-hoc On-demand Distance Vector, neuRFon) to automatically construct a low-speed ad-hoc network of nodes. In most large network instances, the network will be a cluster of clusters. It can also form a mesh or a single cluster. The current profiles derived from the ZigBee protocols support beacon and non-beacon enabled networks.

In non-beacon-enabled networks (those whose beacon order is 15), an unslotted CSMA/CA channel access mechanism is used. In this type of network, ZigBee Routers typically have their receivers continuously active, requiring a more robust power supply. However, this allows for heterogeneous networks in which some devices receive continuously, while others only transmit when an external stimulus is detected. The typical example of a heterogeneous network is a wireless light switch: The ZigBee node at the lamp may receive constantly, since it is connected to the mains supply, while a battery-powered light switch would remain asleep until the switch is thrown. The switch then wakes up, sends a command to the lamp, receives an acknowledgment, and returns to sleep. In such a network the lamp node will be at least a ZigBee Router, if not the ZigBee Coordinator; the switch node is typically a ZigBee End Device.

In beacon-enabled networks, the special network nodes called ZigBee Routers transmit periodic beacons to confirm their presence to other network nodes. Nodes may sleep between beacons, thus lowering their duty cycle and extending their battery life. Beacon intervals may range from 15.36 milliseconds to 15.36 ms * 214 = 251.65824 seconds at 250 kbit/s, from 24 milliseconds to 24 ms * 214 = 393.216 seconds at 40 kbit/s and from 48 milliseconds to 48 ms * 214 = 786.432 seconds at 20 kbit/s. However, low duty cycle operation with long beacon intervals requires precise timing, which can conflict with the need for low product cost.

In general, the ZigBee protocols minimize the time the radio is on so as to reduce power use. In beaconing networks, nodes only need to be active while a beacon is being transmitted. In non-beacon-enabled networks, power consumption is decidedly asymmetrical: some devices are always active, while others spend most of their time sleeping.

ZigBee devices are required to conform to the IEEE 802.15.4-2003 Low-Rate Wireless Personal Area Network (WPAN) standard. The standard specifies the lower protocol layers—the physical layer (PHY), and the media access control (MAC) portion of the data link layer (DLL). This standard specifies operation in the unlicensed 2.4 GHz (worldwide), 915 MHz (Americas) and 868 MHz (Europe) ISM bands. In the 2.4 GHz band there are 16 ZigBee channels, with each channel requiring 5 MHz of bandwidth. The center frequency for each channel can be calculated as, FC = (2405 + 5 * (ch - 11)) MHz, where ch = 11, 12, ..., 26.

The radios use direct-sequence spread spectrum coding, which is managed by the digital stream into the modulator. BPSK is used in the 868 and 915 MHz bands, and OQPSK that transmits two bits per symbol is used in the 2.4 GHz band. The raw, over-the-air data rate is 250 kbit/s per channel in the 2.4 GHz band, 40 kbit/s per channel in the 915 MHz band, and 20 kbit/s in the 868 MHz band. Transmission range is between 10 and 75 meters (33 and 246 feet) and up to 1500 meters for zigbee pro, although it is heavily dependent on the particular environment. The maximum output power of the radios is generally 0 dBm (1 mW).

The basic channel access mode is "carrier sense, multiple access/collision avoidance" (CSMA/CA). That is, the nodes talk in the same way that people converse; they briefly check to see that no one is talking before they start. There are three notable exceptions to the use of CSMA. Beacons are sent on a fixed timing schedule, and do not use CSMA. Message acknowledgments also do not use CSMA. Finally, devices in Beacon Oriented networks that have low latency real-time requirements may also use Guaranteed Time Slots (GTS), which by definition do not use CSMA.

ZigBee RF4CE
On March 3, 2009 the RF4CE (Radio Frequency for Consumer Electronics) Consortium agreed to work with the ZigBee Alliance to jointly deliver a standardized specification for radio frequency-based remote controls. ZigBee RF4CE is designed to be deployed in a wide range of remotely-controlled audio/visual consumer electronics products, such as TVs and set-top boxes. It promises many advantages over existing remote control solutions, including richer communication and increased reliability, enhanced features and flexibility, interoperability, and no line-of-sight barrier.

Software and hardware
The software is designed to be easy to develop on small, inexpensive microprocessors. The radio design used by ZigBee has been carefully optimized for low cost in large scale production. It has few analog stages and uses digital circuits wherever possible.

Even though the radios themselves are inexpensive, the ZigBee Qualification Process involves a full validation of the requirements of the physical layer. This amount of concern about the Physical Layer has multiple benefits, since all radios derived from that semiconductor mask set would enjoy the same RF characteristics. On the other hand, an uncertified physical layer that malfunctions could cripple the battery lifespan of other devices on a ZigBee network. Where other protocols can mask poor sensitivity or other esoteric problems in a fade compensation response, ZigBee radios have very tight engineering constraints: they are both power and bandwidth constrained. Thus, radios are tested to the ISO 17025 standard with guidance given by Clause 6 of the 802.15.4-2006 Standard. Most vendors plan to integrate the radio and microcontroller onto a single chip.

Source: http://en.wikipedia.org

Wi-Fi 802.11n

noreply@blogger.com (Secred Admirer) — Sun, 28 Feb 2010 00:31:00 +0000

IEEE 802.11n is an amendment to the IEEE 802.11-2007wireless networking standard to improve network throughput over the two previous standards — 802.11a and 802.11g — with a significant increase in the maximum raw data rate from 54 Mbit/s to 600 Mbit/s with the use of four spatial streams at a channel width of 40 MHz.

Since 2007, the Wi-Fi Alliance has been certifying interoperability of "draft-N" products based on what was draft 2.0 of IEEE 802.11n specification. The Alliance has upgraded its suite of compatibility tests for some enhancements finalized after draft 2.0. Furthermore, it has affirmed that all draft-n certified products remain compatible with the products conforming to the final standards.

Description
IEEE 802.11n is an amendment to IEEE 802.11-2007 as amended by IEEE 802.11k-2008, IEEE 802.11r-2008,IEEE 802.11y-2008, and IEEE 802.11w-2009, and builds on previous 802.11 standards by adding multiple-input multiple-output(MIMO) and 40 MHz channels to the PHY (physical layer), and frame aggregation to the MAC layer.
MIMO is a technology which uses multiple antennas to coherently resolve more information than possible using a single antenna. One way it provides this is through Spatial Division Multiplexing (SDM). SDM spatially multiplexes multiple independent data streams, transferred simultaneously within one spectral channel of bandwidth. MIMO SDM can significantly increase data throughput as the number of resolved spatial data streams is increased. Each spatial stream requires a discrete antenna at both the transmitter and the receiver. In addition, MIMO technology requires a separate radio frequency chain and analog-to-digital converter for each MIMO antenna which translates to higher implementation costs compared to non-MIMO systems.
40 MHz channels is another feature incorporated into 802.11n which doubles the channel width from 20 MHz in previous 802.11 PHYs to transmit data. This allows for a doubling of the PHY data rate over a single 20 MHz channel. It can be enabled in the 5 GHz mode, or within the 2.4 GHz if there is knowledge that it will not interfere with any other 802.11 or non-802.11 (such as Bluetooth) system using those same frequencies. Coupling MIMO architecture with wider bandwidth channels offers increased physical transfer rate over 802.11a (5 GHz) and 802.11g (2.4 GHz).

Data encoding
The transmitter and receiver use precoding and postcoding techniques, respectively, to achieve the capacity of a MIMO link. Precoding includes spatial beamforming and spatial coding, where spatial beamforming improves the received signal quality at the decoding stage. Spatial coding can increase data throughput via spatial multiplexing and increase range by exploiting the spatial diversity, through techniques such as Alamouti coding.

Number of antennas
The number of simultaneous data streams is limited by the minimum number of antennas in use on both sides of the link. However, the individual radios often further limit the number of spatial streams that may carry unique data. The notation helps identify what a given radio is capable of. The first number (a) is the maximum number of transmit antennas or RF chains that can be used by the radio. The second number (b) is the maximum number of receive antennas or RF chains that can be used by the radio. The third number (c) is the maximum number of data spatial streams the radio can use. For example, a radio that can transmit on two antennas and receive on three, but can only send or receive two data streams would be .

The 802.11n draft allows up to . Common configurations of 11n devices are , , and . All three configurations have the same maximum throughputs and features, and differ only in the amount of diversity the antenna systems provide. In addition, a fourth configuration, is becoming common, which has a higher throughput, due to the additional data stream.

Data rates
Data rates up to 600 Mbit/s are achieved only with the maximum of four spatial streams using a 40 MHz-wide channel. Various modulation schemes and coding rates are defined by the standard and are represented by a Modulation and Coding Scheme (MCS) index value. The table below shows the relationships between the variables that allow for the maximum data rate.

Source: http://en.wikipedia.org

Token Ring/FDDI Networks

noreply@blogger.com (Secred Admirer) — Fri, 26 Feb 2010 14:46:00 +0000

An illustration of a token ring's token passing

General

A token passing ring LAN is a group of computers connected in a loop. The group uses a token passing access mechanism. A computer wishing to send data should first receive permission. When it gets control of the network it may transmit a frame. Each frame transmitted on the ring is transmitted from one computer to the next, until it ultimately returns to the initiator of the transmission.
The Token Passing Ring Network was originally developed by IBM and only Ethernet LANs are more popular. The IEEE 802.5 specification which was modeled after IBM's Token Ring is almost identical and the term Token Ring is used to refer both specifications.
FDDI (Fiber Distributed Data Interconnect) is an improved token ring specification based on fiber as the physical medium. As opposed to Token Ring's single ring, FDDI, uses two to achieve better results. CDDI, yet another standard, resembles FDDI, but uses a copper wire for its ring.

Characteristics

Comparison of basic characteristics

Topology

Token Ring LANs use a ring topology, i.e. each station is connected to two other stations which are all together arranged in a loop. Each station can send a signal along the loop after receiving permission to do so (Only one station may have control on the network at
a specific point of time). The signal will travel from one station to the other until it reaches its initiator.

Priority System

Token Ring networks has a priority system that allows stations with high priority to use the network more frequently. The priority is defined by the frame's priority and reservation fields. In order to seize a token a station must have priority which equals or is higher than the priority field of the token. Only than the station can reserve the token for the next pass around the network. This way when the next token is generated, it includes the higher reserving station. Stations must change the priority back to its previous value after their transmission has completed.

Fault Management Mechanisms

In order to detect and correct network faults Token Ring networks may dedicate a station for monitoring frames which are circling around without being dealt with. This monitor removes such frames and allow the network to function in a normal manner all over again.

FDDI - Self healing

As described above FDDI networks implements a recovery mechanism which enable the network to function properly even under a broken ring. FDDI uses two rings to achieve recovery capabilities. As shown a token is passed simultaneously on the network's inner and outer rings which backup each other.
As shown in the following figure in case of broken connection or station malfunction, the closest station closes the network loop by sending the token it received from the outer/inner ring back using the inner/outer ring. This feature is called Self healing.

Frame Format

Token Ring Frame Formats (tokens and data/command)

Tokens consist of:

Start delimiter - which alerts the stations of a token arrival (or data/command frame).
Access control byte - which contains the priority and reservation fields, a token bit to differentiate token from data/command frame and a monitor bit checking whether a frame is circling the ring endlessly.
End delimiter - which signals the end of a frame, end of a logical sequence and damaged frames.

Data/Command Frames carry information for upper-layer protocols.
After the Access control byte a frame control byte arrives and indicates whether it is a data or control information (and which) frame. Then arrives two address fields (source & destination) each 6 bytes long. Data follows these fields (its length depends on the time each station can hold a token) and then a FCS (frame check sequence) field. At the end as in tokens, an end delimiter completes the frame.

Source: http://www3.rad.com

IPv6

noreply@blogger.com (Secred Admirer) — Thu, 25 Feb 2010 07:51:00 +0000

According to experts, the Internet as we know it will face a serious problem in a few years. Due to its rapid growth and the limitations in its design, there will be a point when no more free addresses are available for connecting to new hosts. At that point, no more new web servers can be set up, no more users can sign up for accounts at ISPs, and no more new machines can be set up to access the web or participate in online games -- some people might call this a serious problem.
Several approaches have been made to solve the problem. A very popular approach is to not assign a worldwide unique address to every user's machine, but rather to assign them "private" addresses, and hide several machines behind one official, globally unique address. This approach is called "Network Address Translation" (NAT, also known as "IP masquerading"). It has problems, as the machines hidden behind the global address can't be addressed, and as a result of this, opening connections to them -- which are used in online gaming, peer-to-peer networking, etc. -- is not possible. For a more in-depth discussion of the drawbacks of NAT, see [RFC3027].

A different approach to the problem of Internet addresses getting scarce is to abandon the old Internet protocol with its limited addressing capabilities, and use a new protocol that does not have these limitations. The protocol -- or actually, a set of protocols -- used by machines connected to form today's Internet is known as the TCP/IP (Transmission Control Protocol, Internet Protocol) suite, and version 4 currently in use has all the problems described above.

Switching to a different protocol version that does not have these problems of course requires for a "better" version to be available. And actually, there is a better version. Version 6 of the Internet Protocol (IPv6) fulfills future demands on address space, and also addresses other features such as privacy, encryption, and better support of mobile computing.

Assuming a basic understanding of how today's IPv4 works, this article is intended as an introduction to the IPv6 protocol. The changes in address formats and name resolution are covered. After that, it is shown how to use IPv6 -- even if your ISP doesn't offer it -- by using a simple-yet-efficient transition mechanism called 6to4. The goal is to to get online with IPv6, giving example configurations for BSD Unix and Linux.

What good is IPv6?
When telling people to migrate from IPv4 to IPv6, the question you usually hear is "Why?". There are actually a few good reasons to move to the new version:

Bigger address space
Support for mobile devices
Built-in security

Bigger address space
The bigger address space IPv6 offers is the most obvious enhancement it has over IPv4. While today's Internet architecture is based on 32-bit wide addresses, the new version has 128-bit technology available for addressing. Thanks to the enlarged address space, workarounds like NAT don't have to be used anymore. This allows full, unconstrained IP connectivity for today's IP-based machines as well as upcoming mobile devices like PDAs and cell phones -- all will benefit from full IP access through GPRS and UMTS.

Mobility
When mentioning mobile devices and IP, it's important to note that a special protocol is needed to support mobility, and implementing this protocol -- called "Mobile IP" -- is one of the requirements for every IPv6 stack. Thus, if you have IPv6 going, you have support for roaming between different networks, with global notification when you leave one network and enter the other one. Support for roaming is possible with IPv4 too, but there are a number of hoops that need to be jumped in order to get things working. With IPv6, there's no need for this, as support for mobility was one of the design requirements for IPv6. See [RFC3024] for some more information on the issues that need to be addressed with Mobile IP on IPv4.

Security
Besides support for mobility, security was another requirement for the successor to today's Internet Protocol version. As a result, IPv6 protocol stacks are required to include IPsec. IPsec allows authentication, encryption, and compression of IP traffic. Except for application-level protocols like SSL or SSH, all IP traffic between two nodes can be handled without adjusting any applications. The benefit of this is that all applications on a machine can benefit from encryption and authentication, and that policies can be set on a per-host (or even per-network) basis, not per application/service. An introduction to IPsec with a roadmap to the documentation can be found in [RFC2411], the core protocol is described in [RFC2401].

Changes to IPv4
After giving a brief overview the important features of IPv6, we'll go into the details of the basics of IPv6. A brief understanding of how IPv4 works is assumed, and the changes in IPv6 will be highlighted. Starting with IPv6 addresses and how they're split up, we'll go into the various types of addresses there are, what became of broadcasts; then discuss the IP layer, changes for name resolving, and what's new in DNS for IPv6.

Addressing
An IPv4 address is a 32-bit value that's usually written in "dotted quad" representation, where each "quad" represents a byte value between 0 and 255, for example:

127.0.0.1

This allows a theoretical number of 2^32 or ~4 billion hosts to be connected on the Internet. Due to grouping, not all addresses are available today.

IPv6 addresses use 128-bit technology, which results in 2¹²⁸ theoretically addressable hosts. This allows a really big number of machines to be addressed, and it will fit all today's requirements plus PDAs, cell phones, and even IP phones in the near future without any sweat. When writing IPv6 addresses, they are usually divided into groups of 16 bits written as four hex digits, and the groups are separated by colons. An example is:

fe80::2a0:d2ff:fea5:e9f5

This shows a special thing -- a number of consecutive zeros can be abbreviated by a single "::" once in the v6 number. The above address is thus equivalent to fe80:0:00:000:2a0:d2ff:fea5:e9f5 -- leading zeros within groups can be omitted.

To make addresses manageable, they are split in two parts, which are the bits identifying the network a machine is on, and the bits that identify a machine on a network or subnetwork. The bits are known as netbits and hostbits, and in both IPv4 and v6, the netbits are the "left," or most significant bits of an IP number; and the host bits are the "right," or least significant bits:

+--------------------+--------------------+

| n netbits | 128-n hostbits |

+--------------------+--------------------+

In IPv4, the border is drawn with the aid of the netmask, which can be used to mask all net/host bits. Typical examples are 255.255.0.0 which uses 16-bit for addressing the network, and 16-bit for the machine, or 255.255.255.0 which takes another 8 bits to allow addressing 256 subnets on, for example, a class B net.

When addressing switched from classful addressing to CIDR routing, the borders between net and host bits stopped being 8-bit boundaries, and as a result the netmasks started looking ugly and became unmanageable. As a replacement, the number of network bits is used for a given address, to denote the border. Thus

10.0.0.0/24

is the same as a netmask of 255.255.255.0 (24 single bits).

The same scheme is used in IPv6:

2001:638:a01:2::/64

tells us that the address used here has the first (left-most) 64 bits used as the network address, and the last (right-most) 64 bits are used to identify the machine on the network. The network bits are commonly referred to as the (network) "prefix", and the prefix here would be 64 bits.

Common addressing schemes found in IPv4 are the (old) class B and class C nets. With a class C network (/24), 24 bits are assigned by your provider, which leaves 8 bits to be assigned by you. If you want to add any subnetting to that, you end up with "uneven" netmasks that are a bit tricky to deal with. Class B networks (/16) are easier cases where only 16 bits are assigned by the provider, and systems that allow subnetting, or splitting of the right-most bits into two parts -- one to address the on-site subnet, and one to address the hosts on that subnet. Usually, this is done on byte (8-bit) boundaries. Using a netmask of 255.255.255.0 (or a /24 prefix) allows flexible management even of bigger networks. Of course there is the upper limit of 254 machines per subnet, and 256 subnets.

With 128 bits available for addressing in IPv6, the scheme commonly used is the same, only the fields are wider. Providers usually assign /48 networks, which leaves 16 bits for a subnetting and 64 host bits.

The idea behind having fixed-width, 64-bit wide host identifiers is that they aren't assigned manually as in IPv4. Instead, v6 host addresses are recommended (not mandated!) to be built from so-called EUI64 addresses. EUI64 addresses are -- as the name says -- 64-bits wide, and derived from MAC addresses of the underlying network interface. For example, with Ethernet, the 6-byte (48-bit) MAC address is usually filled with the hex bits "fffe" in the middle -- the MAC address

01:23:45:67:89:ab

results in the EUI64 address

01:23:45:ff:fe:67:89:ab

which again gives the host bits for the IPv6 address.

::0123:45ff:fe67:89ab

These host bits can now be used to automatically assign IPv6 addresses to hosts, which supports autoconfiguration of v6 hosts -- all that's needed to get a complete v6 IP number is the first (net/subnet) bits. IPv6 also offers a solution to assign them automatically.

When on a network of machines speaking IP, there's usually one router which acts as the gateway to outside networks. In IPv6 land, this router will send "router advertisement" information which clients are expected to either receive during operation or solicit upon startup. The router advertisement information includes data on the router's address, and which address prefix it routes. With this information and the host-generated EUI64 address, a v6-host can calculate its IP number, and there is no need for manual address assignment. Of course, routers still need some configuration.

The advertisement information routers create is part of the Neighbor Discovery Protocol (NDP, see [RFC2461]), which is the successor to IPv4's ARP protocol. In contrast to ARP, NDP does not only do lookup of v6 addresses for MAC addresses (the neighbor solicitation/advertisement part), but also does a similar service for routers and the prefixes they serve, which is used for autoconfiguration of v6 hosts as described in the last paragraph.

Multiple addresses
In IPv4, a host usually has one IP number per network interface -- or even per machine if the IP stack supports it. Only very rare applications like web servers result in machines having more than one IP number.

In IPv6, this is different. For each interface, there is not only a globally unique IP address, but there are two other addresses that are of interest: The link-local address, and the site-local address. The link-local address has a prefix of fe80::/64, and the host bits are built from the interface's EUI64 address. The link-local address is used for contacting hosts and routers on the same network only, the addresses are not visible or reachable from different subnets. If desired, there's the choice of either using global addresses (as assigned by a provider), or using site-local addresses.

Site-local addresses are assigned the network address fec0::/10, and subnets and hosts can be addressed just as for provider-assigned networks. The only difference is, that the addresses will not be visible to outside machines, as these are on a different network, and their site-local addresses are in a different physical net (if assigned at all). As with the 10/8 network in IPv4, site-local addresses can be used, but don't have to be. For IPv6, it's most common to have hosts assigned a local link and a global IP address. Site-local addresses are rather uncommon today, and is no substitute for globally unique adresses if global connectivity is required.

Multicasting
In IP land, there are three ways to talk to a host: unicast, broadcast, and multicast. The most common way to talk to a host is by talking to it directly using its unicast address. In IPv4, the unicast address is the "normal" IP address assigned to a single host, with all address bits assigned. The broadcast address used to address all hosts in the same IP subnet has the network bits set to the network address, and all host bits set to "1" (which can be easily done using the netmask and some bit operations). Multicast addresses are used to reach a number of hosts in the same multicast group, which can be machines spread across the Internet. Machines must join multicast groups explicitly to participate, and there are special IPv4 numbers used for multicast addresses, allocated from the 224/8 subnet. Multicast isn't used very much in IPv4, and only few applications like the MBone audio and video broadcast utilities use it.
In IPv6, unicast addresses are used the same as in IPv4, no surprise there -- all the network and host bits are assigned to identify the target network and machine. Broadcasts are no longer available in IPv6 in the way they were in IPv4, this is where multicasting comes into play. Addresses in the ff::/8 network are reserved for multicast applications, and there are two special multicast addresses that supersede the broadcast addresses from IPv4. One is the "all routers" multicast address, the others is for "all hosts". The addresses are specific to the subnet, for example, a router connected to two different subnets can address all hosts/routers on any of the subnets it's connected to. Addresses here are:

ff0X::1 for all hosts and
ff0X::2 for all routers,

where "X" is the scope ID of the link here, identifying the network. Usually this starts from "1" for the "node local" scope, "2" for the first link, etc. Note that it's perfectly OK for two network interfaces to be attached to one link, thus resulting in double bandwidth:

Several interfaces attached to a link result in only one scope ID for the link.

One use of the "all hosts" multicast is in the neighbor solicitation code of NDP, where any machine that wants to communicate with another machine sends out a request to the "all hosts" group, and the machine in question is expected to respond.

Name resolution

After all the talk about addressing in IPv6, it might make one wonder if there's a proper way to abstract all those long and ugly IPv6 addresses with nice host names as one can do in IPv4, and of course there is.

Host name to IP number resolution in IPv4 is usually done in one of three ways: through a simple table in /etc/hosts, by using the Network Information Service (NIS, formerly YP), or via the Domain Name System (DNS).

As of this writing, NIS/NIS+ over IPv6 is currently only available on Solaris 8, for both database contents and transport, using an RPC extension.

Having a simple address <-> name map like /etc/hosts is supported in all IPv6 stacks. Depending on the implementation, /etc/hosts either contains v6 addresses as well, or there will be a separate file that only maps v6 addresses to names. Examples for /etc/hosts that are capable of v6 addresses are the KAME-based IP stacks found in the BSD operating systems (NetBSD, FreeBSD, etc.) and /etc/ipnodes used by the USAGI Linux stack and Solaris. Other implementations may use different files.

For DNS, there are no fundamentally new concepts. IPv6 name resolution is done with AAAA records that -- as the name implies -- point to an entity that's four times the size of an A record. The AAAA record takes a hostname on the left side, just as A does; and on the right side, there's an IPv6 address, such as

noon IN AAAA 3ffe:400:430:2:240:95ff:fe40:4385

For the reverse resolution, IPv4 uses the in-addr.arpa zone, and below that it writes the bytes (in decimal) in reversed order (the most significant bytes are to the right). For IPv6 this is similar, only hex digits representing 4 bits are used instead of decimal numbers and resource records are also under a different domain, ip6.int.

So to have the reverse resolution performed for the above host, you would put a line like this into your /etc/named.conf file:

zone "0.3.4.0.0.0.4.0.e.f.f.3.IP6.INT" {

type master;

file "db.reverse";

};

and in the zone file db.reverse you put (besides the usual records like SOA and NS):

5.8.3.4.0.4.e.f.f.f.5.9.0.4.2.0.2.0.0.0 IN PTR noon.ipv6.example.com.

The address is reversed here and written down one hex digit after the other, starting with the least significant (right-most) one with the hex digits separated by dots, as in zone files.

One thing to note when setting up DNS for IPv6 is to take note of the DNS software version in use. BIND 8.x does understand AAAA records, but it does not offer name resolution via IPv6. You need BIND 9.x for that. Beyond that, BIND 9.x supports a number of resource records that are currently being discussed but not officially introduced yet. The most noticeable one here is the A6 record which makes it easier to change the provider or prefix.

In summary, this article talked about the technical differences between IPv4 and IPv6 for addressing and name resolution. Some details like IP header options, QoS, and flows were deliberately left out to simplify this explanation.

Source : http://onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html

Charging in Telecommunication

noreply@blogger.com (Secred Admirer) — Wed, 17 Feb 2010 10:15:00 +0000

Charging
Charging associated with collecting detailed data about a conversation or use of services. Based on these data made the determination, the generation and recording meter pulses and their accumulation, which can be processed further to calculate the cost of such a conversation or service.
Billing
Making records showing the amount to be paid by each customer to the operator of the right has been using the services provided by operators.
Aspect Rates
Rates for PSTN services, IDN and mobile, generally consists of two components:

Basic component is the burden of network usage, which is the basis for closing costs and services depends on the use of network facilities junctions.
Specific component is the load for the installation and use of the network. This load depends on the type and facilities and / or regions. This burden consists of: initial installation fee (once only when installed) subscription fee or monthly rent. Basic facilities charges cost an additional feature usage

Along with the advancing of the society prosperity, telecommunication is becoming one of the basic needs. The extensive size of the Indonesian territory with the geographical condition consists of many islands and spread out of community are the potential market in
naming the telecommunication businesses.
To enhance the availability of telecommunication services, the Government enacted the Law No. 3 year 1989 regarding the telecommunication services and Ministrial Decree No. 79 year 1995 regarding the guide line of telecommunication service basic rates adjustment. Pricing system using price cap is a formula used by PT TELKOM in determining the annual increasing of telecommunication service rates. This price cap is a formula an approach to resolves the maximum changes of telecommunication service rates considering inflation rate (consumer price index), productivity and external factors.
The objectives of this study are to reveal telecommunication service rates structure, the link age of the price cap formula to telecommunication service rates structure and to apportion the increasing of telecommunication service rates for all subscriber's categories. The result of this study shows that the price cap formula and the operational cost structure are related in determining the increasing of telecommunication service rates. Based on the Government Decree, the maximum apportionment is 30% for social subscribers and above 30%
is allowed for residential and business subscribers. However the appropriate apportionment according to subscriber's willingness to pay is 10%. The increasing of telecommunication rates are affected to monthly cost, usage of domestic and long distance direct dialing, but not affected to new installation cost. The analysis shows that 35% increasing rates results in additional company's profit and telecommunication access as amount 2% and economic growth 6% then for 38% increasing rates results in additional company's profit and telecommunication access as amount 3% and economic growth 9%.

VoIP

noreply@blogger.com (Secred Admirer) — Wed, 10 Feb 2010 10:41:00 +0000

Generic VoIP Numbering

The proposed numbering format is as follows:
n [n] 111 aa [a] gg eeee [e]
where:
n [n] = e164 appropriate national code, the length of 1 to 2 digits
Important Note:

For Indonesia, n [n] can be replaced with the number zero (0), for example: 62 111 = 0 111
Next we will consider only numbers beginning with the prefix 0 111.

aa [a] = area code area code in accordance with Telkom(Indonesia), the length of 2 to 3 digits and is not preceded by the numbers 0 (zero).
gg = Regional code Gatekeeper, the length of two-digit numbers and does not contain 0 (zero).
eeee [e..] = endpoint number or numbers + Local Gatekeeper Endpoint number, length free home since the sum total of the first n not more than 14 digits and is not preceded by the numbers 0 (zero).

Regulation
Interconnectivity of VoIP to other types of telecommunication networks in Indonesia remains an issue, as regulation imposed by the Indonesian government governs only outgoing calls from VoIP to telecommunication operators, not incoming calls from operators to VoIP.

This implies that the government does not fully integrate their numbers into e164arpa, the Electronic Number Mapping System association acknowledged by the International Telecommunication Union.

To deal with this problem, ODC will request ENUM number allocation from e164.org, a free provider operated by the Internet Telephony Users Association, a non-profit association. Just like e164arpa, e164.org allows users to register their normal home telephone line as a VoIP line. This will enable VR to reach VoIP clients or normal telephone numbers also registered to the e164.org database –complementing the already established system and providing an alternative to users to make their calls. To become part of e164.org, however, ODC needs to adjust VR's briker, to make it capable of running well under the SIP environment, the protocol used by e164.org. However, the project is limited to demonstrating a model applicable to other countries.

Connection
There are three ways in which you can make a VoIP connection, each way having a different set of requirements and implications. The three ways are differentiated by what you have on each of the two communicating sides.

Computer to Computer
This mode is the most common, as it is so easy and free. You need to have a computer connected to the Internet, with the necessary hardware to speak and listen (either a headset or speakers and a microphone). You can install voice communication software like Skype and you are ready to talk.

Obviously, this mode will work only if you have a correspondent who is using a computer equipped like yours to communicate. She should be connected at the same time. It’s like chatting, but with voice.

This can happen not only on the Internet, but on a Local Area Network (LAN) as well. The network should be IP-enabled, i.e. the Internet Protocol (IP) should be running and controlling packet transfer on your network. This way, you can communicate with another person on the same network.

Whether you are communicating over the Internet or a LAN, you need to have adequate bandwidth. If you have around 50 kbps, it will work, but you won’t have great quality. For good quality voice, get at least 100 kbps for a conversation.

Phone to Phone
This mode is very handy, but is not as simple and cheap to set up as the other two. It implies using a phone set on each end to communicate. Thus you can use VoIP and take advantages of its low cost by using a phone set and speak to another person using a phone set as well. There are two ways in which you can use phones to make VoIP calls:

Using IP Phones:
An IP Phone looks just like a normal phone. The difference is that instead of working on the normal PSTN network, it is connected to a gateway or router, a device which, simply said, does the necessary mechanisms to get the VoIP communication running. The IP phone therefore does not connect to the RJ-11 socket. Instead, it uses the RJ-45 plug, which is the one we use for wired LANs. If you want to have an idea of what a RJ-11 plug is, have a look at your normal phone or your dial-up modem. It is the plug that connects the wire to the phone or modem. The RJ-45 plug is similar, but bigger.

You can of course use wireless technologies like Wi-Fi to connect to a network. In this case, you can either be using a USB or RJ-45 for connection.

Using an ATA:
ATA is short for Analog Telephone Adapter. It is a device that allows you to connect a standard PSTN phone to your computer or directly to the Internet. The ATA converts voice from your normal phone and converts it to digital data ready to be sent over a network or the Internet.

If you register for VoIP service, it is common to have an ATA bundled along in the service package, which you can return once you terminate the package. For example, you get an ATA in a package with Vonage and AT&T’s CallVantage. You only have to plug the ATA to your computer or and phone line, install the necessary software, and you are ready to use your phone for VoIP.

Phone to Computer and vice-versa
Now that you understand how you can use your computer, normal phones and IP phones to make VoIP calls, it is easy to figure out that you can call a person using a PSTN phone from your computer. You can also use your PSTN phone to call someone on his computer.

You can also have a mixture of VoIP users, using phones and computers to communicate over the same network. The hardware and software are heavier in this case.

Telecommunication Network Blog

noreply@blogger.com (Secred Admirer) — Mon, 08 Feb 2010 07:35:00 +0000

This blog is dedicated to Telecommunication Network lecture

Qushay Bagas Isworo

114081009

SK 32 01