Selected IP Traffic Offload (SIPTO)

The industry is developing a new standard called Selected IP Traffic Offload (SIPTO). SIPTO allows internet traffic to flow from the femtocell directly to the internet, bypassing the operator’s core network, as shown in Figure 8 below.

More information on LIPA and SIPTO can be obtained from:

1. 3GPP TR 23.829: Local IP Access and Selected IP Traffic Offload (http://www.3gpp1.eu/ftp/Specs/archive/23_series/23.829/)

2. Femtocells – Natural Solution for Offload (http://www.3gamericas.org/documents/016+Femtocells+Natural+Solution+for+Offload%5B1%5D.pdf)

Local IP Access (LIPA) for Femtocells

I blogged about data offload earlier, for Femtocells. This traffic offload can be done via a feature called Local IP Access (LIPA). If you have LIPA support in your Home NodeB (HNB) or Home eNodeB (HeNB) then once you have camped on your Femtocell then you can access your local network as well as the network's IP network.

This would mean that you can directly print from your mobile to the local printer or access other PC's on your LAN. Note that I am also referring to access via Dongle as Mobile access though in practice I dont see much point of people just using dongles when they are in their Home Zone. Every laptop/notebook/netbook is now Wifi enabled so this situation doesnt benefit much for the dongle access.

I am sure there are quite a few unresolved issues with regards to the Security of the data, the IP address allocation, QoS, etc.

Continuous computing have a white paper on LIPA available that can be obtained by registering here. Anyway, enough information is available even without getting the PDF.

There is also a small presentation here that gives a bit of idea on LIPA.

As usual any comments, insights and references welcome.

IPv6 Consideration in LTE

IPv6 Consideration in LTE

View more presentations from Zahid Ghadialy

More Information on similar topic is available at:

• 6deploy
• Tutorials
• 6DISS
• Workshops
• Tutorials

'Internet Kill' switch and IPv9

Slightly off topic today as I was going through the pile of information and I caught attention of this news article that for some reason has not been reported by major newspapers. The article says that the president of USA will have the 'Kill' switch to kill off internet (temporarily i guess) in case of a major emergency like war, etc. Joseph Liberman who proposed this idea has since then backed away saying that he meant that parts of Internet can be disconnected like they do in China.

This brought into attention the other article I was going through about IPv9. Yes thats correct, I did write IPv9. I first heard about IPv9 back in 2004-5 but then it was dismissed as nothing serious. Apparently Chinese government backed Ministry of Information Industry (MII) has been promoting this IPv9. According to an old TelecomAsia.net article:

Back in July 2004, reports of a Chinese IPv9 prompted a bewildered reaction from internet godfather Vint Cerf. 'What could this possibly be about‾ As far as I know, IANA [Internet Assigned Numbers Authority] has not allocated the IPv9 designation to anyone. IPv9 is not an Internet standard. Could you please explain what is intended here‾" he wrote in an email to China's internet leaders.

The idea was dismissed as a "rogue" project with no official backing. But it is back on the table led, now as then by Xie Jianping, the head of the Shanghai Universal Institute of Chemical Technology and more recently in charge of the decimal network standards team in the MII's science and technology department.

The project returned to prominence at a press conference at the unusual location of the Party Central School in Beijing two weeks ago, where Xie announced that the networking technology had been successfully tested by China Netcom and the Ministry of Commerce.

He asserted that the project is all about China wresting control of its own IP networks away from US dominance for which, he claimed, China was paying 500 billion yuan a year.

The system reportedly uses numerical addressing to make China "the only country able to unify domain names, IP addresses and MAC addresses" into a single, metric system, according to Xinhua. Without any explanation, Xinhua said it also made China the only country outside the US "to have root servers and IP address hardware connectivity servers and its own domain name, IP address and MAC address resources".

In an interview with a skeptical Sina reporter, Xie and denied the project was another Hanxin - a reference to a fraudulent state-backed chip project.

"Our IPv9 has gone through testing and assessment," he said adding that he could not give any more detail but would "make public some material at the necessary time."

But the system, or what little is known of it, has plenty of doubters at home. Sina said critics of the system complain that turning domain names and brand names into numerals is a "backwards step" for the net.

The fact that the decimal network appears to asset control over root servers is bound to alarm internet governance bodies around the world.

And whatever else might be said about it, the project is clearly backed by the MII. "IPv9" raises more questions than answers.

So it looks like the Chinese government may have been expecting some 'Kill Switch' in the future by the US government and is probably creating a backup based on a new approach so that the users within China remain connected to their Internet.

Any thoughts and opinions are more than welcome...

MBMS, Digital TV and IP Triple Play in China

Apparently according to this report by Xuefei (Michael) Peng, MBMS is alive and kicking in China with around 200,000 users already. I cant find more info so if anybody who can fill more info is more than welcome.

The government of mainland China has formulated a general plan to launch triple-play services, integrating telecom networks, broadcast and TV networks, and Internet together.

From 2010 to 2012, China will focus on the trial integration of broadcast and TV services and telecom services (including Internet services), dealing with any related policies. From 2013 to 2015, based on the trial experience, China will promote the integration nationwide.

In the coming five years, various sectors will prepare in different ways to meet the goals stated in the general plan. Telecom operators such as China Mobile, China Unicom, and China Telecom will invest more to promote IPTV services and accelerate FTTX deployment. Meanwhile, broadcast and TV operators will accelerate cable-TV network integration and interactive TV services development and will more actively develop value-added Internet services.

Broadcast and TV operators are currently strong in video content and wireless broadcast, while telecom operators own two-way fixed-line networks, mobile networks, and Internet services.

The differences between broadcast and TV operators across different regions and the uneven distribution of telecom fixed-line networks and mobile networks can offer cooperation opportunities.

Notably, almost all provinces of China already have launched IPTV services. The total number of IPTV service users in China has exceeded 5 million. However, problems with IPTV content must be solved, and the price for IPTV services also needs to be lowered to attract more users and compete with digital TV.

Meanwhile, the transformation of cable-TV networks from one way to two way has been sped up. Two-way cable-TV networks now cover over 24 million users. In the coming three years, broadcast and TV operators will invest over US$5 billion to continue to change 100 million one-way cable-TV links into two-way cable TV.

Eventually, through cable-TV networks, broadcast and TV operators hope to run Internet access services. This has been in trial use in some provinces. In order to run Internet access services, however, broadcast and TV operators need to rent bandwidth from telecom operators, greatly increasing the potential cost of service.

Another aspect of the triple play involves the conversion of mobile services to triple play. Mobile-phone TV is an emerging service in China. Up to now, mobile-phone TV services based on the China Multimedia Mobile Broadcasting (CMMB) standard have reached 1.5 million users. However, the current CMMB standard only supports one-way communication. So the users can only receive broadcast-TV programs via mobile.

On the other hand, mobile services based on the broadcast multicast Multimedia Broadcast Multicast Service (MBMS) standard serve about 200,000 users. The growing 3G user base will convert to the MBMS standard. Additionally, the government policy will affect the mobile-phone TV market too. So it is not clear yet which mobile-phone TV standard will dominate the industry in the future.

Quick preview of 3GPP Release-11 Features and Study items

Release 11 Features

Advanced IP Interconnection of Services

The objective is to specify the technical requirements for carrier grade inter-operator IP Interconnection of Services for the support of Multimedia services provided by IMS and for legacy voice PTSN/PLMN services transported over IP infrastructure (e.g. VoIP). These technical requirements should cover the new interconnect models developed by GSMA (i.e. the IPX interconnect model) and take into account interconnect models between national operators (including transit functionality) and peering based business trunking. Any new requirements identified should not overlap with requirements already defined by other bodies (e.g. GSMA, ETSI TISPAN). Specifically the work will cover:

• Service level aspects for direct IP inter-connection between Operators, service level aspects for national transit IP interconnect and service level aspects for next generation corporate network IP interconnect (peer-to-peer business trunking).

• Service layer aspects for interconnection of voice services (e.g. toll-free, premium rate and emergency calls).

• Service level aspects for IP Interconnection (service control and user plane aspects) between Operators and 3rd party Application Providers.

To ensure that requirements are identified for the Stage 2 & 3 work to identify relevant existing specifications, initiate enhancements and the development of the new specifications as necessary.


Release 11 Studies

Study on IMS based Peer-to-Peer Content Distribution Services

The objectives are to study IMS based content distribution services with the following aspects:

- Identifying the user cases to describe how users, operators and service providers will benefit by using/deploying IMS based content distribution services. such as with the improvement of Peer-to-Peer technology. The following shall be considered:

- Mobile access only (e.g. UTRAN, E-UTRAN, I-WLAN);

- Fixed access only (e.g. xDSL, LAN);- Fixed and mobile convergence scenarios;

- Identifying service aspects where IMS network improvements are needed to cater for content distributed services for above accesses;

- Evaluating possible impacts and improvements on network when IMS based content distribution services are deployed;

- Identifying QoS, mobility, charging and security related requirements in the case of content distribution services on IMS;

- Identifying potential copyright issues;

Study on Non Voice Emergency Services

The Non Voice Emergency Services could support the following examples of non-verbal communications to an emergency services network:

1. Text messages from citizen to emergency services

2. Session based and session-less instant messaging type sessions with emergency services

3. Multi-media (e.g., pictures, video clips) transfer to emergency services either during or after other communications with emergency services.

4. Real-time video session with emergency services

In addition to support the general public, this capability would facilitate emergency communications to emergency services by individuals with special needs (e.g., hearing impaired citizens).

The objectives of this study include the following questions for Non Voice Emergency Services with media other than or in addition to voice:

1. What are the requirements for Non Voice Emergency Services?

2. What are the security, reliability, and priority handling requirements for Non Voice Emergency Services?

3. How is the appropriate recipient emergency services system (e.g., PSAP) determined?

4. Are there any implications due to roaming?

5. Are there any implications to hand-over between access networks

6. Are there any implications due to the subscriber crossing a PSAP boundary during Non Voice Emergency Services communications (e.g., subsequent text messages should go to the same PSAP)?

7. Do multiple communication streams (e.g., voice, text, video emergency services) need to be associated together?

8. What types of “call-back” capabilities are required?9. Investigate the load impact of Non Voice Emergency Services in the case of a large scale emergency event or malicious use.

Non Voice Emergency Services will be applicable to GPRS (GERAN, UTRAN) and to EPS (GERAN, UTRAN, E-UTRAN and non-3GPP).

Study on UICC/USIM enhancements

The intent of this study item is to identify use cases and requirements enabling Mobile Network Operators to distribute new services based on the USIM, to improve the customer experience and ease the portability and customisation of operator-owned and customer-owned settings from one device to another (such as APN and other 3G Notebook settings, graphical user interface, MNO brand, Connection Manager settings,…), and help in reducing operation costs and radio resources usage.

Objectives of this study item are:

-To identify use cases and requirements for new USIM

-based services taking into account the GSMA Smart SIM deliverables;

- To identify use cases and requirements for the USIM used inside terminals with specialised functionalities (e.g. radio modems, 3G Notebook terminals) taking into account the GSMA 3GNBK deliverables;

- To identify use cases and requirements to drive the evolution from the traditional USAT to a multimedia USIM toolkit support, with a particular aim to the Smart Card Web Server;

Study on Alternatives to E.164 for Machine-Type Communications

M2M demand is forecast to grow from 50M connections to over 200M by 2013. A large number of these services are today deployed over circuit-switched GSM architectures and require E.164 MSISDNs although such services do not require "dialable" numbers, and generally do not communicate with each other by human interaction.

Without technical alternative to using public numbering resources as addresses, and considering the current forecasts and pending applications for numbers made to numbering plan administration agencies, there is a significant risk that some national numbering/dialling plans will run out of numbers in the near future, which would impact not only these M2M services but also the GSM/UMTS service providers in general.

The Objective is to determine an alternative to identify individual devices and route messages between those devices. Requirements for this alternative include:

- Effectively identify addressing method to be used for end point devices

- Effectively route messaging between those devices

- Support multiple methods for delivering messages, as defined by 22.368

- Support land-based and wireless connectivity

- Make use of IP-based network architectures

- Addressing/identifiers must support mobility and roaming- support on high speed packet

-switched networks when available and on circuit-switched networks

- Consider if there are security issues associated with any alternatives

Quality of Service (QoS) and Deep Packet Inspection (DPI)

One of the things I mentioned in my presentation in the LTE World Summit was that differentiation of Services based on Quality of Services is required to be able to charge the users more.
This QoS can be varied based on deep inspection of the packets which can tell the operator as to what service a particular packet belongs to. The operators can thus give higher priority to the services and applications that are recommended by them and also block certain services that can be deemed as illegal or unproductive (like file sharing or P2P).

Continuous Computing claims to be one of the market leaders in producing the DPI systems. You can read this article by Mike Coward who is the CTO and Co-founder of Continuous computing here.

There is also this very interesting paper on QoS control in 3GPP EPS which is available freely here.

Please feel free to comment or suggest how do you see DPI being used in the future.

IPv6 transition in cellular networks gaining momentum

IPv6 is good and we all know that. I has been talked for years but practically it hasnt found much success. Verizon made some noise last year but I am not sure of the conclusion.

Just to recap, IPv4 was introduced back in 1982 and IPv6 work started since 1995. IPV4 uses 32 bit (4 bytes) addresses while IPV6 uses 128 bit (16 bytes) addresses. Theoretically we would now have 2^96 times more addresses than in case of IPv4.

Most of network infrastructure manufacturers have their equipment ready for IPv6 as some of the handset manufacturers. The main driver being that someday soon IPv4 addresses would be exhausted (Internet Assigned Numbers Authority will run out of IPv4 addresses in September of 2011, based on current projections) and their equipment would be ready to provide IPv6 addresses without any problems.

Recently, IETF-3GPP Workshop on IPv6 in cellular networks was held in San Francisco, USA on 1 - 2 March, 2010. There are lots of interesting presentations available here for people who want to dig a bit deeper. The concluding report that summarises the presentations and discussions are available here. Here is a brief summary from one of the reports (with links at the end):

Summary

• Scenarios for IPv6 migration were discussed based on 3GPP Technical Report 23.975
• The discussion focused on validating the scenarios
• General IPv6 transition and deployment guidelines were outlined based on input from IETF
• Solutions for migration and v4-v6 co-existence were presented
  
• Solutions included existing RFCs and working group items but also proposals in Internet Drafts
• Gap analysis wrt transition scenarios was discussed

Conclusions on scenarios

• Scenarios 1 and 3 based on dual-stack and IPv6-only deployments were generally recognized as valid
• See docs IPW100013, IPW100028
• Scenario 2 was also recognized as valid, addressing two separate problems related to insufficient RFC1918 space and subscriber identification
• See doc IPW100027
• Scenario 4 did not receive wide support from the workshop, largely because it was felt that it addressed a problem already solved by other scenarios
• Variants of some of these scenarios were brought up during the discussions, conclusions were not reached on these
• These may need further discussion

Conclusions on solutions

• It was recognized that necessary support in the network and devices is already available to “switch on” IPv6 in 3GPP networks
• Some networks reported running dual stack
• Some networks reported running IPv6-only now
• Solutions enhancing existing mechanisms for dual stack deployments and new solutions for IPv6-only deployments drew wide support
• Gateway-initiated Dual Stack Lite
• Stateful IPv4/IPv6 translation

Next steps: 3GPP

• IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
• Note that the workshop itself does not have the mandate to make formal decisions
• 3GPP is expected to identify possible normative specification impacts, if any, of the preferred solutions
• A need was identified to provide more operational guidelines about IPv6 deployment to 3GPP operators
• The best location for these guidelines is FFS (e.g. 3GPP TR 23.975, GSMA, etc)

Next steps: IETF

• IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
• Note that the workshop itself does not have the mandate to make formal decisions
• IETF is encouraged to continue working on stateless and stateful IPv4/IPv6 translation mechanisms
• These mechanisms are being worked on in IETF BEHAVE group
• IETF is also encouraged to consider new solutions that are not yet working group items
• Gateway Initiated DS Lite
• Per-interface NAT44 bindings addressing IPv4 address shortage
• Note that the workshop has not set any timelines

Further reading:

• 3GPP TR 23.975: IPv6 Migration Guidelines, Release 10 (http://www.3gpp.org/ftp/Specs/archive/23_series/23.975/)
• 'IETF-3GPP Workshop on IPv6 in cellular networks' Workshop Presentations (http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/)
• 'IETF-3GPP Workshop on IPv6 in cellular networks' Workshop Summary Report(http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Report/)
• 3G Americas Report on 'Transitioning to IPv6' (http://3gamericas.org/documents/2008_IPv6_transition_3GA_Mar2008.pdf)
• Is IPv6 Finally on the Verge? - Light Reading (http://www.lightreading.com/document.asp?doc_id=189143)
• Jari Arkko's Publications (http://www.arkko.com/publications.html)

Inter-Layer Communication Primitives

IEEE defines service primitives that are used for communication between different layers in a protocol stack. There are 4 types of service primitives as can be seen in the diagram above and are described below:

Request: This is sent by the initiating side and from a higher layer to a lower layer. For example when RRC wants to send a message to peer RRC entity, it sends an RLC Data Request to RLC.

Indication: This primitive on the receiving entity is passed from Layer N to the layer above (N+1). For example when RLC entity receives MAC data from MAC and its addressed to RRC, it sends RLC Data Ind to the RRC.

Response: This is the response to the Indication on the receiving entity. So in our example case, RLC Data Resp would be sent by RRC when it receives RLC Data Ind.

Confirm: This is used as a reply in the sending entity as the lower layer conveys the result of one or more previous request primitives. The confirm will generally contain status code indicating success or failure of the procedure. In our example, RLC Data Cnf will be sent by RLC as a response to RLC Data Req.

Verizon's bold step towards IPv6

Verizon is taking bold step of mandating the devices that connect to its LTE Network support IPv6. The following is from Telecom Asia via Network World:

According to device requirements Verizon released earlier this year, any device that hooks onto the LTE network currently being built on the 700MHz band "shall support IPv6" and further states that "the device shall be assigned an IPv6 address whenever it attaches to the LTE network." The requirements make support for IPv4 optional and state that any device supporting IPv4 "shall be able to support simultaneous IPv6 and IPv4 sessions."

IPv6 is a long-anticipated upgrade to the Internet's main communications protocol, which is known as IPv4.

As CircleID blogger and Pennsylvania State University senior systems programmer Derek Morr notes, the adoption of IPv6 is going to be particularly important for wireless carriers that are expecting a surge in mobile data traffic in the next few years, as they will need a fresh batch of Internet addresses to handle the multitude of wireless devices that will hook onto their networks.

"The problem, of course, is that we're running out of IPv4 addresses," Morr writes. "The IANA pool will most likely be depleted by the end of 2010. This has led many people to wonder if LTE deployments will require IPv6. Now we have an answer: Yes."

Verizon is planning to launch its LTE services commercially in 25 to 30 U.S. markets in 2010. The network will be the first mobile broadband network in the United States to be based on the LTE standard, which is the latest variation of Global Systems for Mobile Communications (GSM) technology that is used for 3G High-Speed Packet Access (HSPA) networks. AT&T and T-Mobile have also announced plans to commercially launch LTE networks after 2010, while Sprint has already commercially launched its high-speed mobile WiMAX network.

One of the biggest drivers for carriers upgrading their mobile data networks to 4G technologies is the expected explosion in demand for mobile video services. A recent Cisco study on Internet traffic trends projects that 64% of mobile data traffic will be for video by 2013, vs. 19% for data services, 10% for peer-to-peer and 7% for audio. The study also says that the projected video traffic will increase four-fold between now and 2012

You may also want to read my post on the case for early LTE in USA.

Difference between SDU and PDU

This question keeps propping up in many discussions so here is an explanation for the difference between PDU and SDU.



Going back to the basics, a protocol stack consists of many different individual protocols. Protocols can be simply described as set of rules that allow communication between peer entities or they can also be described as set of rules that facilitate horizontal communication. Now these protocols are arranged in layers as can be seen in the figure above. In the transmitter side, a layer N receives data from layer N+1 and this data is called the SDU or Service Data Unit. This layer will modify the data and convert it into a PDU or a Protocol Data Unit. The peer entity in the receiver is only able to understand this PDU.

In simplest form, this modification by layer N of the layer N+1 SDU contains encapsulation. In encapsulation, the SDU is preserved as it is and an additional header is added by the layer N protocol. The modification can also perform concatenation (where more than one SDU is combined in a single PDU), segmentation (where a SDU can be split so that different parts of it end up in different PDU) and padding (where SDU is so small that filler bits are added in the end to complete the PDU).

In the receiver side, the peer entity receives the PDU from layer N-1 (its actually layer N-1 SDU) and convert it back into SDU(s) and passes it to layer N+1.

The figure above shows an example of RLC SDU and PDU. The SDU's are received from higher layer, which is from PDCP in case of LTE. These SDU's have to be converted to PDU's so they undergo segmentation and concatenation and suitable RLC headers are added to form the RLC PDU's.

First Figure Source: The TCP/IP Guide

Second Figure Source: 3G Evolution - HSPA and LTE for Mobile Broadband, Erik Dahlman et al.

Healthcare using BWA (Broadband Wireless Access)

Came across this paper entitiled "IEEE 802.16/WiMAX-based broadband wireless access and its application for telemedicine/e-health services". While it is common sense that any prehospital diagnosis and monitoring can be very helpful it is important to make sure that the information is updated properly and with correct QoS.

Ambulances and other medical emergency vehicles travel at extremely high speeds. This would require that the technology in place is able to handover between different cells and keeps the equipment connected to the server. The nurse should concentrate on the patient rather than worry about the link being maintained electronically. This also necessitates a quaranteed QoS being maintained for this setup to work effectively. The figure above shows the QoS that is required in different situations.

In the above mentioned paper, the authors argue that WiMAX/802.16 networks can be engineered for telemedecine/e-health services. The main focus should be on Radio Resource allocation and admission control policy. Other important thing is to remember while implementing to use TCP for loss sensitive data and UDP for delay sensitive (but loss in-sensitive) applications.

I am sure the healthcare industry is already looking in these kinds of options and its just matter of time before we will hear about some new related application.

IPv6! One small step for man, one giant leap for mankind

3G Americas has published a whitepaper urging wireless service providers to start making a transition plan asap.

Anyone who has studied TCP/IP in their studies would know the basic problem with IPv4 is that the address is only 32 bits long and this allows a theoretical maximum of 2^32 addresses. Ofcourse practically the number would be far less because some of the address are either reserved or wasted due to the way the networks are designed (Subnets, etc).

To overcome this sometime in the beginning of 1990's IPv6 was formulated with 128 bit address. This would mean unique IP address to every street lamp is possible without us worrying about depletion of the addresses. Ofcourse the human nature is such that they dont change their behaviour untill forced to and this is the same reason IPv6 is not been used popularly.

When 3G was being standardised one of the main goals was also to use IPv6 exclusively but then everyone chickened out citing various problems and continuity of services.

Anyway, this new 3G Americas paper has laid down a plan and possible pitfalls that would be encountered when transitioning to IPv6. The following is a self explanatory summary for the report:

To transition to IPv6 or not? A critical question for many service providers is when to transition to IPv6. As pointed out earlier, IPv6 has several benefits which will result in a simpler, more powerful and more efficient network. The sooner a service provider achieves these benefits, the sooner it will be at a competitive advantage compared to service providers who delay transition. The risks of delaying the transition are the following:

 Managing a dwindling IPv4 address space will become increasingly expensive. Address
allocation requires careful planning; previously assigned address blocks may need to be
recovered, which is a complex process; and the management of additional devices such as
Network Address Translation (NAT) devices add to the cost.

 The service provider that delays transition to IPv6 may not be able to deliver the same
services as service providers that have made the transition to IPv6. The ability to support
always-on and peer-to-peer services is impaired when traffic has to traverse NAT devices.
For example, always-on services require that a user is always reachable and therefore
cannot share a pool of public addresses with other devices. This can be mitigated through
address and port translation, but also that has its limitations.

 At some point, a service provider who has not made the transition to IPv6 may become
unattractive as a roaming partner to service providers who have made the transition. The
same may be true in retail/wholesale relationships.

On the other hand, transitioning to IPv6 at an early stage also has certain risks. The transitioning process is complex. It requires a significant investment in planning and training. During the transition period, the service provider must run both IPv4 and IPv6 systems concurrently, which leads to an increase in operational expenses. Furthermore, there is a risk of service interruption, customer dissatisfaction and penalties. All service providers will need to go through this, but an early adopter may run into problems which later adopters could avoid.

In the end, we believe that service providers don’t have the option to delay IPv6 introduction. The exhaustion of IPv4 addresses will force a transition to IPv6, and as pointed out earlier, address exhaustion may become a reality within the next five years. From that point on, service providers will face an increase in operations cost, if not because of introduction of IPv6, then due to the complexity of running an IPv4-only network with a diminishing pool of addresses.

With careful planning, the risk of early adoption can be mitigated significantly.

Carrier Ethernet Transport (CET)

Another technology being discussed nowadays is Carrier Ethernet Transport (CET). Though this is not a wireless technology as such, it would still be very important as (can be seen from the diagram) the user data will be carried over this to the core.

A simple and straightforward explanation was not as easy to find but here are some more details which will give you a good idea.

Good source of introduction is this article from Meriton Networks:

Carriers around the world are increasingly being pressured to provide new services while reducing their costs to remain competitive with changing regulations and new, non-traditional entrants into the marketplace. As carriers migrate to next-generation networks (NGNs) to reduce their costs and improve their ability to support high bandwidth-intensive services with guaranteed SLAs, they need a flexible, scalable optical transport
infrastructure – especially in the metro network – that efficiently supports
Ethernet and minimizes operational complexities.

Carrier Ethernet Transport (CET) is an architectural approach to building scalable transport infrastructure for supporting Ethernet and the evolution to NGNs

* Carrier Ethernet Transport integrates intelligent WDM (ability to do multi-degree switching at wavelength and sub wavelength levels) with
Ethernet Tunnels, such as PBB-TE and T-MPLS .
* Carrier Ethernet Transport (CET) provides the simplicity and cost-effectiveness of native Ethernet with the reliability and power of WDM to deliver unparalleled flexibility, efficiency and cost savings
* Note that “Carrier Ethernet” comprises two distinct sub-segments: “Carrier Ethernet Services” and “Carrier Ethernet Transport”

Carrier Ethernet Transport is an architecture for NGNs based on wavelength networking. Services from both wireless and wireline access networks are simultaneously carried on a single network infrastructure. Three levels of embedded transport networking switching capabilities (wavelength, sub-wavelength, and Ethernet tunnels) provide a cost-effective transport network that can support services with guaranteed service level agreements (SLAs).

A good introduction is an article in Lightwave titled, "Carrier Ethernet transport: No longer 'if,' but 'how'". There are some very good diagrams explaining the concept and its difficult to reproduce them here.

Another article in Converge! Network Digest suggests that CET is not the only way and there are alternative technologies available. The main advantage with CET is that it can reduce complexity compared to its main rivals.

CET offers the following direct benefits to carriers as they migrate to NGN:

• Maximizing the amount of Ethernet traffic that can be switched and routed without leaving the optical transport layer
• Reducing the load on expensive MPLS systems and precious LSPs
• Reducing the number of expensive optical ports required at metro/core hub points
• Providing a circuit-orientated transport model similar to SDH/SONET – which has great benefits from an OSS and operational perspective
  

Additionally, CET provides an architecture that clearly separates the service and transport layers. Separation is an important attribute to allow the independent and efficient scaling of the service and transport layers. Separation also allows the transport layer to focus on its main task in the network – to provide to the access and service networks a large volume of circuit-orientated point-to-point paths that are deterministic and reliable.

Finally the article that made me curious about this subject was this article from Telecommunications Online (Part1 Part2) which is an interview of a Nokia-Siemens manager. Some interesting points as follows:

Telecommunications: You mentioned CET. Although it’s still an early concept, how are service providers responding to the idea at this time?

Bar-on: The perspective is very positive. CET is optimized transport Layer-2 carrier packet traffic. Traffic is growing tremendously. Sometimes you hear a number of 100 percent per-year growth in some carriers, but the average number would be about 70 percent. Everyone realizes the infrastructure needs to be packet-optimized. The way we present CET is it’s a combination of Ethernet and WDM. This has been positively received when looked at by carriers. You can have an argument as to what protocols to use, but CET is the next transport layer. Many carriers are looking for a migration from the current TDM- based infrastructure to a packet
optical-based infrastructure.

Telecommunications: Outside of traditional enterprise services, there’s a lot of talk about using Ethernet for wireless backhaul. Albeit it’s still early, are your carrier customers investigating Ethernet for that application?

Bar-on: We do see a strong requirement from carriers doing wireless backhaul over Ethernet. It’s driven by two elements happening in the market:

1. Base Station Migration: The base stations themselves are migrating from TDM/ATM to 4G or Ethernet. We have the luxury in that we manufacture both the base station and the transmission equipment. We have a dedicated solution because we understand both ends of the market. It’s quite clear that Ethernet will play a role in 4G deployments.

2. Pseudowires: On the other side, carriers are looking to reuse their opex to carry 2G and 3G over Ethernet with Pseudowire rather than SONET/SDH networks. We see it mainly coming from competitive carriers that are trying to fight on the backhaul business to fight with traditional ILECs and PTTs. Having said that we at Nokia Siemens are providing a solution that addresses the current scenario where you have 2G, 3G, and a migration for 4G. What you see in both cases is this metro Ethernet network not only has to address not only Ethernet traffic, but also highly sensitive voice traffic over TDM. For that we believe that concepts like connection-oriented Ethernet can provide five-9s reliability for this kind of service. It’s no longer just about Ethernet access.

Telecommunications: Earlier you mentioned Carrier Ethernet Transport (CET). One of the emerging debates to come out of the CET concept is the use of Provider Backbone Transport (PBT)/Provider Backbone Bridging-Transport Engineering (PBB-TE). How are these concepts resonating with the service provider community?

Bar-on: We’re seeing that everyone is interested in that and want to see if it’s real. Major carriers in the U.S. are very interested in the technology and are in a position to see that it’s real and it’s working. If you look at the cycle of technology, we are probably in the early beginning of the deployment of this technology at least in the U.S. market. We see other groups in Europe going quicker and are leading the camp here, but no one can really ignore this thing. Even if I look at the RFPs by major U.S. carrier out in the market some of them are including requirements for PBT/PBB-TE. If you think about this now and where we were a year ago that’s a major step.

Moving towards IP Convergence

IP Convergence implies the carriage of different types of traffic such as voice, video, data, and images over a single network. The integrated network is based on the Internet Protocol (IP).

The reason I am talking about this is because of the way things are moving; everything converging to IP based core. Most network operators and enterprises need to understand how to rapidly transform or evolve their wireless, wireline or enterprise networks into all-IP backbones quickly and effectively to stay competitive and differentiate themselves. This “IP transformation” brings with it an array of communications, applications, service delivery and network challenges.

As service providers and enterprises take steps to plan and manage their IP transformation efforts, they are confronted by fundamental changes IP has impacted on the technology landscape. Convergence is happening at a rapid rate — IT systems, networks, services and applications are blending together. The ability to integrate different platforms, applications, content, and services from a variety of vendors has become essential not only to improve costs, but also to enhance network reliability, security, and efficiency.

Service providers and enterprises need to differentiate to compete better, add new subscribers, and offer new advanced communications services and applications. For service providers, it means providing customers the services they want, when they want them, from anywhere they are, while consistently delivering a higher quality of experience. For enterprises, it may imply lowering network costs by providing new value and extending the lifecycle of existing network assets.

Services transformation: As shifting demands, greater expectations, and the emphasis on the user experience continue to reshape today’s market, the ability to adjust to new conditions and rapidly take advantage of emerging opportunities is more important than ever.

For carriers, this means being able to review current service offerings and expand or tailor them accordingly. Here are a few examples:
· Migrating from a new standalone service like IPTV and adding mobile TV and VoIP to create a triple-play offer;
· Migrating from fixed VoIP and adding mobility via Fixed Mobile Convergence (FMC); and
· Utilizing IMS to move toward a Service Delivery Environment (SDE), thus enabling access to which with the right underpinnings can be seamlessly blended together in a controlled and sophisticated manner to create a new, compelling experience that assures users service delivery.

For enterprises, service transformation could mean enabling new IP-PBX services with advanced mobile technologies. The business case for service transformation must be clear from the beginning. Organizations should not disregard the continued usefulness and reliability of any legacy deployment in place. If in fact the legacy service is out of date or its functionality no longer suits the needs of the organization, then the cost of maintaining it could be a motivating factor for service transformation.

Network transformation: Traditional service providers need to transform their legacy network environment to IP to support innovation and lower their operating expenses. This can be a daunting task. Take for example the implication of moving to distributed architectures, such as IMS, which allow an unprecedented level of vendor diversity. This new level of flexibility opens the door to an unprecedented level of flexibility in solution architectures and introduces the need for extensive interoperability testing that many carriers are finding cannot be left to vendors to sort out on their own.

For traditional operators, a move to IP also entails the planning and management of the migration of millions of customer lines. Likewise, enterprises continue to use IP to converge and transform their networks, adding capabilities that greatly enhance their ability to reduce costs and increase functionality. However, the way employees communicate is growing more complex. They use a range of voice communications like desk phones in the office, mobile phones in their pockets, and IP phone services like GoogleTalk or Skype on their laptops. They use voicemail, e-mail and text messaging, as well as presence- enabled IM. They access Web content and private intranet information. And they do all of this from multiple end-points through different access technologies — from within an enterprise, at home, or remotely.

Business transformation: With market forces and industry trends undergoing disruptive change, leading carrier organizations need an ever greater “transformation tool box” to help navigate the environment to create a new vision for the business, develop the step-by-step roadmap to realize that vision, build the business case to justify investments and identify the operations models that support the business going forward.

Meanwhile, enterprises are rapidly evolving their business models to increase their overall agility to respond better to market conditions. Given mergers, acquisitions, industry consolidation, and shareholder expectations, enterprises will be under continuous pressure to devise new ways to outperform their competitors.

The benefits of IP Convergence:

1. Excellent support for multimedia applications. Improved connectivity means that devices can be assigned specific tasks; the number of devices required is less which makes installation, deployment, and learning an easier task.

2. A converged IP network is a single platform on which interoperable devices can be run in innovative ways. Since IP is an open standard, it is vendor independent and this helps in fostering interoperability and improving network efficiency in terms of time and cost. The ambit of IP convergence encompasses networks, devices, and different technologies and systems that can be operated on a unified infrastructure.

3. A converged IP network is easier to manage because of the uniform setup in which the system resources operate. Training users is easy.

4. An enterprise can achieve flexibility in terms of moulding its communication patterns to its management practices. This is a dynamic process that can be continually improved with collaboration from network partners. What this results in is the right information to the right person at the right time leading to improved decision making.

5. IP networks have proven to be remarkably scalable and this has been one of the prime reasons that even large enterprises have gone ahead with implementing IP. Applications that run on IP networks are available all over the world; in fact most new business applications include inbuilt IP support.

6. An IP convergent network is capable of making use of the developments in class of service differentiation and QoS-based routing. This leads to better utilization of resources and also allows for capacity redundancy to take care of an increase in the number of users.

7. A uniform environment requires fewer components in the network. Smoother maintenance and management result from this and in turn lead to improved processes. Affordable deployment results from the elimination of multiple networks operating in parallel and manageability improves. In a converged environment, fewer platforms need to be tested and gateways between networks are eliminated.

8. Business applications have different tolerance levels for transit delays, dropped packets, and error rates. IP architecture is capable of handling these so that the QoS reflects the requirements of the different applications.

9. Device integration has the potential to simplify end-to-end security management and at the same time make it more robust. Continuous development is taking place in field of security for IP data communication.

10. A converged IP network offers a business tremendous cost savings in terms of hardware and space utilization. It opens up more markets that can be reached, more products that can be introduced, increases employee productivity and mobility, and enables even smaller companies to compete with larger ones because of faster information relay.