Showing posts with label TCP/IP. Show all posts
Showing posts with label TCP/IP. Show all posts

Thursday, 24 July 2025

L4S and the Future of Real-Time Performance in 5G and Beyond

As mobile networks continue to evolve to support increasingly immersive and responsive services, the importance of consistent low latency has never been greater. Whether it is cloud gaming, extended reality, remote machine operation or real-time collaboration, all these applications rely on the ability to react instantly to user input. The slightest delay can affect the user experience, making the role of the network even more critical.

While 5G has introduced major improvements in radio latency and overall throughput, many time-critical applications are still affected by a factor that is often overlooked - queuing delay. This occurs when packets build up in buffers before they are forwarded, creating spikes in delay and jitter. Traditional methods for congestion control, such as those based on packet loss, are too slow to react, especially in mobile environments where network conditions can change rapidly.

Low Latency, Low Loss and Scalable Throughput (L4S), is a new network innovation designed to tackle this challenge. It is an Internet protocol mechanism developed through the Internet Engineering Task Force, and has recently reached standardisation. L4S focuses on preventing queuing delays by marking packets early when congestion is building, instead of waiting until buffers overflow and packets are dropped. The key idea is to use explicit signals within the network to guide congestion control at the sender side.

Applications that support L4S are able to reduce their sending rate quickly when congestion starts to appear. This is done by using ECN, or Explicit Congestion Notification, which involves marking rather than dropping packets. The result is a smooth and continuous flow of data, where latency remains low and throughput remains high, even in changing network conditions.

One of the significant benefits of L4S is its ability to support a wide range of real-time services at scale. Ericsson highlights how edge-based applications such as cloud gaming, virtual reality and drone control need stable low-latency connections alongside high bitrates. While over-the-top approaches to congestion control may work for general streaming, they struggle in mobile environments. This is due to variability in channel quality and radio access delays, which can cause sudden spikes in latency. L4S provides a faster and more direct way to detect congestion within the radio network, enabling better performance for these time-sensitive applications.

To make this possible, mobile networks need to support L4S in a way that keeps its traffic separate from traditional data flows. This involves using dedicated queues for L4S traffic to ensure it is not delayed behind bulk data transfers. In 5G, this is implemented through dedicated quality-of-service flows, allowing network elements to detect and handle L4S traffic differently. For example, if a mobile user is playing a cloud-based game, the network can identify this traffic and place it on an L4S-optimised flow. This avoids interference from other applications, such as file downloads or video streaming.

Nokia's approach further explains how L4S enables fair sharing of bandwidth between classic and L4S traffic without compromising performance. A dual-queue system allows both types of traffic to coexist while preserving the low-latency characteristics of L4S. This is especially important in scenarios where both legacy and L4S-capable applications are in use. In simulations and trials, the L4S mechanism has shown the ability to maintain very low delay even when the link experiences sudden reductions in capacity, which is common in mobile and Wi-Fi networks.

One of the important aspects of L4S is that it requires support both from the application side and within the network. On the application side, rate adaptation based on L4S can be implemented within the app itself, often using modern transport protocols such as QUIC or TCP extensions. Many companies, including device makers and platform providers, are already trialling support for this approach.

Within the network, L4S depends on the ability of routers and radio access equipment to read and mark ECN bits correctly. In mobile networks, the radio access network is typically the key bottleneck where marking should take place. This ensures that congestion is detected at the right point in the path, allowing for quicker response and improved performance.

Although L4S is distinct from ultra-reliable low-latency communication, it can complement those use cases where guaranteed service is needed in controlled environments. What makes L4S more versatile is its scalability and suitability for open internet and large-scale public network use. It can work across both fixed and mobile access networks, providing a common framework for interactive services regardless of access technology.

With L4S in place, it becomes possible to offer new kinds of applications that were previously limited by latency constraints. This includes lighter and more wearable XR headsets that can offload processing to the cloud, or port automation systems that rely on remote control of heavy equipment. Even everyday experiences, such as video calls or online gaming, stand to benefit from a more responsive and stable network connection.

Ultimately, L4S offers a practical and forward-looking approach to delivering the consistent low latency needed for the next generation of digital experiences. By creating a tighter feedback loop between the network and the application, and by applying congestion signals in a more intelligent way, L4S helps unlock the full potential of 5G and future networks.

This introductory video by CableLabs is a good starting point for anyone willing to dig deeper in the topic. This LinkedIn post by Dean Bubley and the comments are also worth a read.

PS: Just noticed that T-Mobile USA have announced earlier this week that they are the first to unlock L4S in wireless . You can read their blog post here and a promotional video is available in the Tweet below ðŸ‘‡

Saturday, 29 June 2019

Presentations from ETSI Security Week 2019 (#ETSISecurityWeek)


ETSI held their annual Security Week Seminar 17-21 June at their HQ in Sophia Antipolis, France. All the presentations are available here. Here are some I think the audience of this blog will like:


Looks like all presentations were not shared but the ones shared have lots of useful information.


Related Posts:

Tuesday, 1 May 2018

MAMS (Multi Access Management Services) at MEC integrating LTE and Wi-Fi networks

Came across Multi Access Management Services (MAMS) a few times recently so here is a quick short post on the topic. At present MAMS is under review in IETF and is being supported by Nokia, Intel, Broadcom, Huawei, AT&T, KT.

I heard about MAMS for the first time at a Small Cell Forum event in Mumbai, slides are here for this particular presentation from Nokia.

As you can see from the slide above, MAMS can optimise inter-working of different access domains, particularly at the Edge. A recent presentation from Nokia (here) on this topic provides much more detailed insight.

From the presentation:

        MAMS (Multi Access Management Services) is a framework for

-            Integrating different access network domains based on user plane (e.g. IP layer) interworking,

-            with ability to select access and core network paths independently

-            and user plane treatment based on traffic types

-            that can dynamically adapt to changing network conditions

-            based on negotiation between client and network
        The technical content is available as the following drafts*



-            MAMS User Plane Specification: https://tools.ietf.org/html/draft-zhu-intarea-mams-user-protocol-02




*Currently under review, Co-authors: Nokia, Intel, Broadcom, Huawei, AT&T, KT,

The slides provide much more details, including the different use cases (pic below) for integrating LTE and Wi-Fi at the Edge.


Here are the references for anyone wishing to look at this in more detail:

Tuesday, 6 February 2018

QUIC - Possibly in 5G, 3GPP Release-16


Over the last year or so, I have heard quite a few discussions and read many articles around why QUIC is so good and why we will replace TCP with QUIC (Quick UDP Internet Connection). One such article talking about QUIC benefits says:

QUIC was initially developed by Google as an alternative transport protocol to shorten the time it takes to set up a connection. Google wanted to take benefits of the work done with SPDY, another protocol developed by Google that became the basis for the HTTP/2 standard, into a transport protocol with faster connection setup time and built-in security. HTTP/2 over TCP multiplexes and pipelines requests over one connection but a single packet loss and retransmission packet causes Head-of-Line Blocking (HOLB) for the resources that were being downloaded in parallel. QUIC overcomes the shortcomings of multiplexed streams by removing HOLB. QUIC was created with HTTP/2 as the primary application protocol and optimizes HTTP/2 semantics.


What makes QUIC interesting is that it is built on top of UDP rather than TCP. As such, the time to get a secure connection running is shorter using QUIC because packet loss in a particular stream does not affect the other streams on the connection. This results in successfully retrieving multiple objects in parallel, even when some packets are lost on a different stream. Since QUIC is implemented in the userspace compared to TCP, which is implemented in the kernel, QUIC allows developers the flexibility of improving congestion control over time, since it can be optimized and better replaced compared to kernel upgrades (for example, apps and browsers update more often than OS updates).

Georg Mayer mentioned about QUIC in a recent discussion with Telecom TV. His interview is embedded below. Jump to 5:25 for QUIC part only

Georg Mayer, 3GPP CT work on 5G from 3GPPlive on Vimeo.

Below are some good references about QUIC in case you want to study further.

Monday, 2 May 2016

Does 5G need 'Next Generation' of Internet Protocols?

I have often heard Martin Geddes mention that the Internet is broken, the protocols (TCP/IP) are wrong and if we want to continue the way our data usage is going, we need to define new protocols (see here for example). It was good to find out last week at 5G Huddle that ETSI is already working on this.


The TCP/IP protocol suite has undoubtedly enabled the evolution of connected computing and many other developments since its invention during the 1970’s. Thanks to the development and ubiquity of this protocol stack, we have managed to build an Internet on which we are dependent as a communications tool, an information storage and distribution tool, a marketing channel and a sales and distribution platform, for consumers and for businesses large and small.

However, the industry has reached a point where forward leaps in the technology of the local access networks will not deliver their full potential unless, in parallel, the underlying protocol stacks used in core and access networks evolve. The development of future 5G systems presents a unique opportunity to address this issue, as a sub-optimal protocol architecture can negate the huge performance and capacity improvements planned for the radio access network.

ETSI has created an Industry Specification Group to work on Next Generation Protocols (NGP ISG), looking at evolving communications and networking protocols to provide the scale, security, mobility and ease of deployment required for the connected society of the 21st century.

The NGP ISG will identify the requirements for next generation protocols and network architectures, from all interested user and industry groups. Topics include:

  • Addressing
  • Security, Identity, Location, Authorization, Accounting/Auditing and Authentication
  • Mobility
  • Requirements from Internet of Things
  • Requirements from video and content distribution
  • Requirements from ultra‐low latency use cases from different sectors (i.e. automotive)
  • Requirements from network operators (e.g. challenges with E2E encrypted content)
  • Requirements from eCommerce
  • Requirements for increased energy efficiency within the global ICT sector.


This ISG is seen as a transitional group i.e. a vehicle for the 5G community (and others of interest) to first gather their thoughts and prepare the case for the Internet community’s engagement in a complementary and synchronised modernisation effort.

The ISG provides a forum for interested parties to contribute by sharing research and results from trials and developments in such a way that a wider audience can be informed. Other standards bodies will be involved so that parallel and concerted standardization action can take place as a further step in the most appropriate standards groups.

Andy Sutton, chair of the NGP recently gave the following presentation in 5G Huddle:



Please feel free to add your opinions in the comments.

Further reading:

**** Added 05/06/2016:20.00 ****
A whitepaper published by ETSI on this topic is available here and embedded below:


Monday, 23 February 2015

Static/Dynamic IP Address Allocation in LTE


I recently came across a discussion on how static and dynamic IP address are allocated in LTE for a UE. Luckily, there is a recent document from Netmanias that discussed this topic. The document is embedded below.



If you enjoyed reading the document (part 1) above, then there is a part 2 here. While in part 1, we saw that IP addresses can be either dynamic or static depending on their allocators, part 2 presents a specific case of IP address allocation – allocation in geographically-separated locations within an LTE network. In case of dynamic allocation, no matter where a user accesses, a dynamically selected P-GW dynamically allocates an IP address to the user for PDN connection. In case of static allocation, however, there is always one specific P-GW and one IP address for a user - the designated P-GW allocates a static IP address for the user’s PDN connection. A case study shows an LTE network that serves two cities as an example to describe different ways and procedures of IP address allocation, and see how they are different from each other.

Sunday, 23 March 2014

Securing the backhaul with the help of LTE Security Gateway


An excellent presentation from the LTE World Summit last year, that is embedded below. The slide(s) that caught my attention was the overhead involved when using the different protocols. As can be seen in the picture above, the Ethernet MTU is 1500 bytes but after removing all the overheads, 1320 bytes are left for data. In case you were wondering, MTU stands for 'maximum transmission unit' and is the largest size packet or frame, specified in octets (8-bit bytes), that can be sent in a packet or frame based network such as the Internet.

Anyway, the presentation is embedded below:


Wednesday, 27 February 2013

Wi-Fi & Packet Core (EPC) Integration

Yesterday I wrote a blog post on whether Wi-Fi is the third RAN in the Metrocells blog. Today I am posting this excellent presentation that details how this Wi-Fi integration with EPC will be done.



Tuesday, 24 April 2012

LTE and IPv6

A discussion on Linkedin prompted me to add some relevant documents relating to LTE and IPv6. Interesting presentation below by Cisco:
Designing LTE with IPv6
View more presentations from Zahid Ghadialy. Available to download from slideshare here.

There are some other interesting presentations on slideshare you may want to look at:



Tuesday, 25 January 2011

MAPCON - Multi Access PDN Connectivity

On Monday, I read Bernard Herscovich, CEO, BelAir Networks saying the following in RCR Wireless:

Wi-Fi is obviously a way to offload data to alleviate congestion, but it also contributes to overall network profitability by delivering data at a lower cost per megabit that traditional macrocells. ABI Research estimates that carrier Wi-Fi can deliver data at 5% the cost of adding cellular capacity. Perhaps the most important driver, though, is the fact that, properly designed and architected, a carrier Wi-Fi network will deliver a consistently great user experience. The implications of that on attracting and retaining subscribers are obvious.

We've also seen cable operators taking advantage of their broadband HFC infrastructure to mount Wi-Fi APs throughout their coverage areas, offering free Wi-Fi as a sticky service to attract and retain home broadband subscribers.

At the GSMA Mobile Asia Congress, back in mid-November, 2010, KDDI's president and chairman explained that while they would be migrating to LTE, which would double their network capacity, data demand in Japan was forecast to increase by 15 times over the next five years. So LTE alone, he admitted, would not be enough. A few weeks before that, European operators, including Deutsche Telekom and Telefonica, were making similar statements at the Broadband World Forum in Paris.

It is clear that LTE alone will not be sufficient to meet ongoing mobile data demand. Technical innovation has resulted in huge capacity gains, but we're now at a point where additional bandwidth is more of a by-product of incremental spectrum. And, we all realize the finite nature of that resource. So, based on this new spectrum, LTE macrocells could deliver a 2 – 4X capacity increase. Meanwhile, ABI estimates that data capacity requirements are increasing 150% per year.

So, it's pretty clear that carriers are going to need more than just an LTE swap out to keep delivering a great user experience. They need to, as many already realize, augment their licensed spectrum with Wi-Fi. KT, the second largest mobile carrier in South Korea, claims to be offloading 67% of their mobile data traffic onto Wi-Fi. There may also be additional unlicensed spectrum made available, at least in the U.S. and the U.K., through the release of so-called white space spectrum, freed up through the switch from analog to digital TV.

It is obvious from the technology point of view that Multiple PDN connections would need to be supported when the UE is using LTE for part of data connection and Wi-Fi for other part. In fact these two (or multiple) connections should be under the control of the same EPC core that can help support seamless mobility once you move out of the WiFi hotspot.

One of the items in 3GPP Release-10 is to do with supporting of multiple Packet Data Networks (PDN) connections for a device. A Release-9 network and the UE can only support 3GPP access based connection via EPC. In Release-10 support for upto 1 non-3GPP access has been added.

FMC100044 specifies the following requirements:

  • The Evolved Packet System supports the following scenarios: a single Operator offering both fixed and mobile access; different Operators collaborating to deliver services across both networks.
  • The Evolved Packet System shall support the access of services from mobile network through fixed access network via interworking.
  • The Evolved Packet System shall be able to support functions for connectivity, subscriber authentication, accounting, Policy Control and quality of service for interworking between the fixed broadband access and Evolved Packet Core.
  • The Evolved Packet System shall optimize QoS and Policy management meaning that it shall offer minimal signalling overhead, while interworking between the fixed broadband access and Evolved Packet Core.
  • The Evolved Packet System shall be able to provide an equivalent experience to users consuming services via different accesses.

The Rel-10 work item extends Rel-9 EPC to allow a UE equipped with multiple network interfaces to establish multiple PDN connections to different APNs via different access systems. The enhancements enable:

  • Establishment of PDN connections to different APNs over multiple accesses. A UE opens a new PDN connection on an access that was previously unused or on one of the accesses it is already simultaneously connected to.
  • Selective transfer of PDN connections between accesses. Upon inter-system handover a UE transfers only a subset of the active PDN connections from the source to the target access, with the restriction that multiple PDN connections to the same APN shall be kept in one access.
  • Transfer of all PDN connections out of a certain access system. A UE that is simultaneously connected to multiple access systems moves all the active PDN connections from the source to target access, e.g. in case the UE goes out of the coverage of the source access.

This work also provides mechanisms enabling operator's control on routing of active PDN connections across available accesses.

The scope of the work is restricted to scenarios where the UE is simultaneously connected to one 3GPP access and one, and only one, non-3GPP access. The non-3GPP access can be either trusted or untrusted.

The design of the required extensions to Rel-9 EPC is based on TR 23.861 Annex A, that provides an overview of the changes that are expected in TS 23.401 and TS 23.402 for the UE to simultaneously connect to different PDNs via different access systems.

See Also:

3GPP TR 23.861: Multi access PDN connectivity and IP flow mobility

3GPP TS 22.278: Service requirements for the Evolved Packet System (EPS)

Old Blog post on Multiple PDN Connectivity

Thursday, 16 December 2010

Packet Flow in 2.5G, 3G, 3.5G and 4G




The 'LTE Signaling' is a very interesting book just being released that is a must have for people who are involved in design, development and testing. A book that explains the basic concepts from beginning till advanced concepts and explains how different components and interfaces fit together.

Though I havent yet read this book, I have read the earlier one titled UMTS Signaling, from the same authors that is an excellent reference for understanding Signalling in UMTS. I have no doubt that this book will be the same high quality.

The Excerpt on Wiley's website provides complete chapter 1 which is quite detailed and the Packet flow pictures and details below is extracted from this book.
The first stage of the General Packet Radio Service (GPRS), that is often referred to as the 2.5G network, was deployed in live networks starting after the year 2000. It was basically a system that offered a model of how radio resources (in this case, GSM time slots) that had not been used by Circuit Switched (CS) voice calls could be used for data transmission and, hence, profitability of the network could be enhanced. At the beginning there was no pre-emption for PS (Packet Switched) services, which meant that the packet data needed to wait to be transmitted until CS calls had been finished.

In contrast to the GSM CS calls that had a Dedicated Traffic Channel (DTCH) assigned on the radio interface, the PS data had no access to dedicated radio resources and PS signaling, and the payload was transmitted in unidirectional Temporary Block Flows (TBFs) as shown in Figure 1.2.

In Release 99, when a PDP (Packet Data Protocol) context is activated the UE is ordered by the RNC (Radio Network Controller) to enter the Radio Resource Control (RRC) CELL_DCH state. Dedicated resources are assigned by the Serving Radio Network Controller (SRNC): these are the dedicated physical channels established on the radio interface. Those channels are used for transmission of both IP payload and RRC signaling – see Figure 1.7. RRC signaling includes the exchange of Non-Access Stratum (NAS) messages between the UE and SGSN.

The spreading factor of the radio bearer (as the combination of several physical transport resources on the Air and Iub interfaces is called) depends on the expected UL/DL IP throughput. The expected data transfer rate can be found in the RANAP (Radio Access Network Application Part) part of the Radio Access Bearer (RAB) assignment request message that is used to establish the Iu bearer, a GPRS Tunneling Protocol (GTP) tunnel for transmission of a IP payload on the IuPS interface between SRNC and SGSN. While the spreading factor controls the bandwidth of the radio connection, a sophisticated power control algorithm guarantees the necessary quality of the radio transmission. For instance, this power control ensures that the number of retransmitted frames does not exceed a certain critical threshold.

Activation of PDP context results also in the establishment of another GTP tunnel on the Gn interface between SGSN and GGSN. In contrast to IuPS, where tunnel management is a task of RANAP, on the Gn interface – as in (E)GPRS – the GPRS Tunneling Protocol – Control (GTP-C) is responsible for context (or tunnel) activation, modification, and deletion.

However, in Release 99 the maximum possible bit rate is still limited to 384 kbps for a single connection and, more dramatically, the number of users per cell that can be served by this highest possible bit rate is very limited (only four simultaneous 384 kbps connections per cell are possible on the DL due to the shortness of DL spreading codes).

To increase the maximum possible bit rate per cell as well as for the individual user, HSPA was defined in Releases 5 and 6 of 3GPP.

In High-Speed Downlink Packet Access (HSDPA) the High-Speed Downlink Shared Channel (HSDSCH) which bundles several High-Speed Physical Downlink Shared Channels (HS-PDSCHs) is used by several UEs simultaneously – that is why it is called a shared channel.

A single UE using HSDPA works in the RRC CELL_DCH state. For DL payload transport the HSDSCH is used, that is, mapped onto the HS-PDSCH. The UL IP payload is still transferred using a dedicated physical data channel (and appropriate Iub transport bearer); in addition, the RRC signaling is exchanged between the UE and RNC using the dedicated channels – see Figure 1.8.

All these channels have to be set up and (re)configured during the call. In all these cases both parties of the radio connection, cell and UE, have to be informed about the required changes. While communication between NodeB (cell) and CRNC (Controlling Radio NetworkController) uses NBAP (Node B Application Part), the connection between the UE and SRNC (physically the same RNC unit, but different protocol entity) uses the RRC protocol.

The big advantage of using a shared channel is higher efficiency in the usage of available radio resources. There is no limitation due to the availability of codes and the individual data rate assigned to a UE can be adjusted quicker to the real needs. The only limitation is the availability of processing resources (represented by channel card elements) and buffer memory in the base station.

From the user plane QoS perspective the two major targets of LTE are:
• a further increase in the available bandwidth and maximum data rate per cell as well as for the individual subscriber;
• reducing the delays and interruptions in user data transfer to a minimum.

These are the reasons why LTE has an always-on concept in which the radio bearer is set up immediately when a subscriber is attached to the network. And all radio resources provided to subscribers by the E-UTRAN are shared resources, as shown in Figure 1.9. Here it is illustrated that the IP payload as well as RRC and NAS signaling are transmitted on the radio interfaces using unidirectional shared channels, the UL-SCH and the Downlink Shared Channel (DL-SCH). The payload part of this radio connection is called the radio bearer. The radio bearer is the bidirectional point-to-point connection for the user plane between the UE and eNodeB (eNB). The RAB is the user plane connection between the UE and the Serving Gateway (S-GW) and the S5 bearer is the user plane connection between the S-GW and public data network gateway (PDN-GW).

The end-to-end connection between the UE and PDN-GW, that is, the gateway to the IP world outside the operator’s network, is called a PDN connection in the E-UTRAN standard documents and a session in the core network standards. Regardless, the main characteristic of this PDN connection is that the IP payload is transparently tunneled through the core and the radio access network.

To control the tunnels and radio resources a set of control plane connections runs in parallel with the payload transport. On the radio interface RRC and NAS signaling messages are transmitted using the same shared channels and the same RLC transport layer that is used to transport the IP payload.

RRC signaling terminates in the eNB (different from 3G UTRAN where RRC was transparently routed by NodeB to the RNC). The NAS signaling information is – as in 3G UTRAN – simply forwarded to the Mobility Management Entity (MME) and/or UE by the eNB.

You can read in detail about all these things and much more from the Wiley's website here.

Thursday, 25 November 2010

LIPA, SIPTO and IFOM Comparison

Enhancing macro radio access network capacity by offloading mobile video traffic will be essential for mobile communications industry to reduce its units costs to match its customer expectations. Two primary paths to achieve this are the use of femtocells and WiFi offloading. Deployment of large scale femtocells for coverage enhancement has been a limited success so far. Using them for capacity enhancements is a new proposition for mobile operators. They need to assess the necessity of using them as well as decide how to deploy them selectively for their heavy users.

Three alternative architectures that are being standardized by 3GPP have various advantages and shortcomings. They are quite distinct in terms of their dependencies and feasibility. Following table is a summary of comparison among these three approaches for traffic offloading.


Looking at the relative strengths of the existing traffic offload proposals, it is difficult to pick an outright winner. SIPTO macro-network option is the most straight-forward and most likely to be implemented rather quickly. However, it doesn't solve the fundamental capacity crunch in the radio access network. Therefore its value is limited to being an optimization of the packet core/transport network. Some other tangible benefits would be reduction in latency to increase effective throughput for customers as well as easier capacity planning since transport facilities don't need to be dimensioned for large number of radio access network elements anymore.

LIPA provides a limited benefit of allowing access to local premises networks without having to traverse through the mobile operator core. Considering it is dependent on the implementation of femtocell, this benefit looks rather small and has no impact on the macro radio network capacity. If LIPA is extended to access to Internet and Intranet, then the additional offload benefit would be on the mobile operator core network similar to the SIPTO macro-network proposal. Femtocell solves the macro radio network capacity crunch. However, the pace of femtocell deployments so far doesn't show a significant momentum. LIPA's market success will be limited until cost of femtocell ownership issues are resolved and mobile operators decide why (coverage or capacity) to deploy femtocells.

IFOM is based upon a newer generation of Mobile IP that has been around as a mobile VPN technology for more than 10 years. Unfortunately success record of mobile IP so far has been limited to enterprise applications. It hasn't become a true consumer-grade technology. Introduction of LTE may change this since many operators spearheading LTE deployments are planning to use IPv6 in handsets and adopt a dual-stack approach of having both IPv4 and IPv6 capability. Since many WiFi access networks will stay as IPv4, DSMIPv6 will be the best tunneling mechanism to hide IPv6 from the access network. Having dual-stack capability will allow native access to both legacy IPv4 content and native IPv6 content from major companies such as Google, Facebook, Yahoo, etc. without the hindrance of Network Address Translation (NAT). Considering the popularity of smartphones such as iPhone, Blackberry and various Android phones, they will be the proving ground for the feasibility of DSMIPv6.

Source of the above content: Whitepaper - Analysis of Traffic Offload : WiFi to Rescue


Wednesday, 24 November 2010

IP Flow Mobility and Seamless Offload (IFOM)

Unlike LIPA or SIPTO that are dependent on upstream network nodes to provide the optimization of routing different types of traffic, IFOM relies on the handset to achieve this functionality. It explicitly calls for the use of simultaneous connections to both macro network, e.g., LTE, UMTS and WiFi. Therefore, IFOM, unlike LIPA and SIPTO, is truly a release 10-onward only technology and it is not applicable for user terminals pre-Release 10. IFOM is being specified via 3GPP TS 23.261 [1]. Following diagram shows the interconnectivity model for IFOM capable UE.


IFOM uses an Internet Engineering Task Force (IETF) Request For Comments (RFC), Dual Stack Mobile IPv6 (DSMIPv6) (RFC-5555) [2].

Since IFOM is based on DSMIPv6, it is independent of the macro network flavor. It can be used for a green-field LTE deployment as well as a legacy GPRS packet core.

Earlier on we looked at the mobile network industry attempts of integration between packet core and WLAN networks. Common characteristic of those efforts was the limitation of the UE, its ability to use one radio interface at a time. Therefore, in earlier interworking scenarios UE was forced to use/select one radio network and make a selection to move to an alternative radio for all its traffic. Today many smartphones, data cards with connection managers already have this capability, i.e., when the UE detects the presence of an alternative access network such as a home WiFi AP, it terminates the radio bearers on the macro network and initiates a WiFi connection. Since WiFi access network and packet core integration is not commonly implemented, user typically loses her active data session and re-establishes another one.

Similarly access to some operator provided services may not be achieved over WiFi. Considering this limitation both iPhone IOS and Android enabled smartphones to have simultaneous radio access but limited this functionality to sending MMS over the macro network while being connected to WiFi only.

IFOM provides simultaneous attachment to two alternate access networks. This allows fine granularity of IP Flow mobility between access networks. Using IFOM, it will be possible to select particular flows per UE and bind them to one of two different tunnels between the UE and the DSMIPv6 Home Agent (HA) that can be implemented within a P-GW or GGSN. DSMIPv6 requires a dual-stack (IPv4 or IPv6) capable UE. It is independent of the access network that can be IPv4 or IPv6.

[1] 3GPP TS 23.261: IP flow mobility and seamless Wireless Local Area Network (WLAN) offload; Stage 2

[2] RFC-5555: Mobile IPv6 Support for Dual Stack Hosts and Routers

[3] 3GPP TS 23.327: Mobility between 3GPP-Wireless Local Area Network (WLAN) interworking and 3GPP systems

Content Source: Analysis of Traffic Offload : WiFi to Rescue

Friday, 10 September 2010

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/)

Thursday, 9 September 2010

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.

Wednesday, 23 June 2010

'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...