Internet of Things – Cisco Systems and Texas Instruments Fighting to Get Their Shares

Internet of Things
IoT or Internet of Things is the most emerging field in wireless access area and many companies are trying to grab their space. Cisco Systems and Texas Instruments are two big names who are collaborating with many companies and startups in hopes of advancing this emerging area.

TI is the first one to grab the opportunity. The networking company already formed partnership with eight companies which include 21emetry, ARM, Arrayent, Exosite, IBM, Spark, Thingsquare and Xively.

Cisco on the other hand launched a challenge to help IoT startups get more visibility. Cisco is looking up for new ideas in IoT applications, analytics, management and connectivity. Each winner will share $250,000 and Cisco will help winners develop, test and pilot new technologies.

According to Gartner forecasts to grow to 26 billion installed units by 2020, representing an almost 30-fold increase from 0.9 billion in 2009.


If You are Interested in Inventions and Patents This Inspiring Video is for You

Ericsson every year choose three inventors who holds largest number of patents in a calendar year. For the year 2013 three leading inventors shared as many as 334 patents between themselves.

Out of these three two are awarded for their work in media and one for wireless access network.


VoLTE Vs Over-the-Top VoIP Services like WhatsApp

VoLTE is the buzzword but is it better than all the Over-the-Top VOIP services offered now. Services including WhatsApp, Skype, Viber or Line all are providing or planning to offer VOIP services. Then why VoLTE. Is VoLTE has any advantages over all the existing services.

According to latest report from NSN Lab, VoLTE is in fact way ahead in terms of battery consumption, network signal load and other aspects.

Over-the-Top (OTT) Clients

VoLTE vs VOIP- Different OTT Services

NSN Lab tested VoLTE against OTT VOIP services hed-to-head with the following KPIs in mind:

  • Smartphone battery consumption
  • Data connections
  • Data volume / throughput
  • Signaling load

Key findings from these test are:

  • OTT VoIP consumed much more smartphone battery power to meet this level of quality
  • OTT VoIP required higher bit rates in general
  • VoLTE client exhibited up to 94% lower mouth to-ear delay compared to OTT VoIP

So VOLTE is the clear winner in all kind of test.

Smartphone battery use

VoLTE clients consumed about 40% less than OTT VoIP clients.

Data connections

OTT VoIP clients generated up to 10x more data connections in the mobile network than a VoLTE client during a call.

Data volume/throughput

Most OTT VoIP applications required between 20% and 40% more throughput than VoLTE clients during active calls to meet this quality level, although one OTT VoIP application showed exceptional performance and came close to VoLTE. Overall data volume consumed over a period of time, including a mix of active and stand-by periods, resulted in at least 50% lower consumption for VoLTE thanks to its more efficient behavior during stand-by.

Signaling load

Typical default OTT VoIP keep-alive patterns activated during standby created between 100% and 200% higher signaling load on LTE networks compared with VoLTE. In one case, an un-optimized OTT VoIP client caused up to 3,000% more signaling in the network during stand-by with default settings.

VoLTE vs Skype vs VOIP &SIP


Anite Announces 4×4 MIMO Support

Anite, a global leader in wireless equipment testing technology today announced 4×4 MIMO device testing capability to support chipset and device manufacturers. Anite will be the first Test Equipment manufacturer to provide chipset and device manufacturers the ability to verify their 4×4 Downlink (DL) MIMO designs and products

The ability to verify 4×4 Downlink (DL) MIMO designs and products is expected to accelerate the development of LTE and LTE-Advanced devices, said Anite.

Advanced MIMO (Multiple Input Multiple Output) antenna configurations where both the base station and the device are equipped with multiple transmit/receive antennas are leading to an increased need for device testing prior to market launch.

MIMO, a key feature in LTE-Advanced, enables operators and device manufacturers to offer superior data rates without requiring additional bandwidth or transmit power, said Anite.

Anite said that 4×4 DL MIMO capable devices require greater antenna separation/isolation and are therefore used in devices with larger form factors such as phablets, laptops with inbuilt modems and set-top boxes, as well as in various automotive applications.

Earlier, Anite demonstrated Carrier Aggregation of two component carriers of 20 MHz each, resulting in Category 6/7 Downlink data rates of 300 Mbps.

‘Complex antenna configurations such as 4×4 DL MIMO require advanced testing capability. Anite’s leading product roadmap and its collaborative engagement with key industry partners enable device manufacturers to accelerate their designs of LTE and LTE-Advanced products’, says Paul Beaver Products Director at Anite.


Intra-LTE Handover Using the S1 Interface

The S1-based handover procedure is used when the X2-based handover cannot be used. These are some examples when S1-based handover can be used.

  1. There is no X2 connectivity to the target eNodeB;
  2. by an error indication from the T-eNB after an unsuccessful X2-based handover;
  3. or by dynamic information learnt by the S-eNB using the STATUS TRANSFER procedure.

The S-eNB initiates the handover by sending a Handover required message over the S1-MME reference point. The EPC does not change the decisions taken by the S-eNB.

The availability of a direct forwarding path is determined in the S-eNB (based on the X2 connectivity with the T-eNB) and indicated to the source MME. If a direct forwarding path is not available, indirect forwarding will be used. The source MME uses the indication from the S-eNB to determine whether to apply indirect forwarding or not.

Intra-LTE Handover Using the S1 Interface Call Flow

Intra-LTE Handover Using the S1 Interface

S1-based Intra-LTE Handover Description

Based on the MEASUREMENT REPORT from the UE, the S-eNB decides to Handover the UE to another eNodeB (T-eNB).

The handover procedure for Intra-LTE handover using the S1 interface is very similar to that of Intra-LTE Handover Using the X2 Interface, except the involvement of the MME in relaying the handover signaling between the S-eNB and T-eNB.

There are two main differences here:

  1. No need for the PATH SWITCH Procedure between the T-eNB and MME, as MME is aware of the Handover.
  2. The SGW is involved in the DL data forwarding if there is no direct forwarding path available between the S-eNB and T-eNB.

Once the Handover is complete, the MME clears the logical S1 connection with the S-eNB by initiating the UE CONTEXT RELEASE procedure.


Intra-LTE Handover Using the X2 Interface

Intra-LTE (Intra-MME/SGW) handover using the X2 interface is used to handover a UE from a source eNodeB (S-eNB) to a target eNodeB (T-eNB) using the X2 interface when the Mobility Management Entity (MME) and Serving Gateway (SGW) are unchanged.

This scenario is possible only when there is a direct connection exists between source eNodeB and target eNodeB with the X2 interface.

Intra-LTE Handover Using the X2 Interface System Architecture

Intra-LTE Handover Using the X2 Interface System Architecture

In case of intra-LTE handover using X2 interface the UE is source eNodeB and is in connected stated and the goal is to move the UE to target eNodeB. The X2 handover procedure is performed without Evolved Packet Core (EPC) involvement, i.e. preparation messages are directly exchanged between the S-eNB and T-eNB. The release of the resources at the source
side during the handover completion phase is triggered by the T-eNB.

Call Flow for Intra-LTE Handover

Call Flow for Intra-LTE Handover

Intra-LTE Handover Call Flow Description

  1. UE is in connected state and a data call is up. Data packets are transferred to/from the UE to/from the network in both directions (DL as well as UL).
  2. The network sends the MEASUREMENT CONTROL REQ message to the UE to set the parameters to measure and set thresholds for those parameters. Its purpose is to instruct the UE to send a measurement report to the network as soon as it detects the thresholds.
  3. The UE sends the MEASUREMENT REPORT to the S-eNB after it meets the measurement report criteria communicated previously. The S-eNB makes the decision to hand off the UE to a T-eNB using the handover algorithm; each network operator could have its own handover algorithm.
  4. The S-eNB issues the RESOURCE STATUS REQUEST message to determine the load on T-eNB (this is optional). Based on the received RESOURCE STATUS RESPONSE, the S-eNB can make the decision to proceed further in continuing the handover procedure using the X2 interface.
  5. The S-eNB issues a HANDOVER REQUEST message to the T-eNB passing necessary information to prepare the handover at the target side (e.g., UE Context which includes the Security Context and RB Context (including E-RAB to RB Mapping) and the Target cell info).
  6. The T-eNB checks for resource availability and, if available, reserves the resources and sends back the HANDOVER REQUEST ACKNOWLEDGE message including a transparent container to be sent to the UE as an RRC message to perform the handover. The container includes a new C-RNTI, T-eNB security algorithm identifiers for the selected security algorithms, and may include a dedicated RACH preamble and possibly some other parameters (i.e., access parameters, SIBs, etc.).
  7. The S-eNB generates the RRC message to perform the handover, i.e, RRCCONNECTION RECONFIGURATION message including the mobilityControlInformation. The S-eNB performs the necessary integrity protection and ciphering of the message and sends it to the UE.
  8. The S-eNB sends the eNB STATUS TRANSFER message to the T-eNB to convey the PDCP and HFN status of the E-RABs.
  9. The S-eNB starts forwarding the downlink data packets to the T-eNB for all the data bearers (which are being established in the T-eNB during the HANDOVER REQ message processing).
  10. In the meantime, the UE tries to access the T-eNB cell using the non-contention-based Random Access Procedure. If it succeeds in accessing the target cell, it sends the RRC CONNECTION RECONFIGURATION COMPLETE to the T-eNB.
  11. The T-eNB sends a PATH SWITCH REQUEST message to the MME to inform it that the UE has changed cells, including the TAI+ECGI of the target. The MME determines that the SGW can continue to serve the UE.
  12. The MME sends a MODIFY BEARER REQUEST (eNodeB address and TEIDs for downlink user plane for the accepted EPS bearers) message to the SGW. If the PDN GW requested the UE’s location info, the MME also includes the User Location Information IE in this message.
  13. The SGW sends the downlink packets to the target eNB using the newly received addresses and TEIDs (path switched in the downlink data path to T-eNB) and the MODIFY BEARER RESPONSE to the MME.
  14. The SGW sends one or more “end marker” packets on the old path to the S-eNB and then can release any user plane / TNL resources toward the S-eNB.
  15. The MME responds to the T-eNB with a PATH SWITCH REQ ACK message to notify the completion of the handover.
  16. The T-eNB now requests the S-eNB to release the resources using the X2 UE CONTEXT RELEASE message. With this, the handover procedure is complete.

Complete Detail of Intra-LTE Handover procedure using X2 interface

Intra-LTE Handover Using the X2 Interface-Call-Flow
Intra-LTE Handover Using the X2 Interface-Call-Flow


  1. LTE X2 Handover PDF
  2. 3GPP TS 36.423: “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP).”
  3. 3GPP TS 25.331: “UMTS Radio Resource Control (RRC) Protocol specification.”

WiFi Offloading ANDSF – Access Network Discovery and Selection Function

The Access Network Discovery and Selection Function (ANDSF) framework was introduced first in 3GPP Release 8 to standardize operator policy mechanism and since then it has evolved in the standard to provide further enhancements like flow mobility and more specific traffic identification.


3GPP Release 8

In Release 8, the ANDSF framework provides access network information; for instance, leveraging Wi-Fi Access Points in the vicinity of the UE location, to enhance the way the UE discovers new non-3GPP Access Networks. It also provides mobility policies in order for the operator to guide the UE to select the proper radio technology in any given location at any given time. Release 8 does not allow simultaneous connections to multiple access networks. For this reason, the Inter System Mobility Policies (ISMPs) were defined independent of the traffic sent by the UE. For example, when a device discovers the presence of Wi-Fi, all the traffic must be offloaded to Wi-Fi or all the traffic must stay on 3G, regardless of what type of traffic is being generated by the applications running on the device.

3GPP Release 10

In Release 10, simultaneous network connections to multiple radio access technologies were enabled by Multi Access PDN Connectivity (MAPCON), IP Flow Mobility (IFOM) and non- seamless Wi-Fi offload. To take this into account, the ANDSF framework has been enhanced with the introduction of Inter System Routing Policies (ISRP), allowing the operator to provide policies based on the traffic exchanged by the UE.

In this way the operator can indicate preferred or forbidden radio access technologies as a function of the type of traffic the UE sends. Specifically an ISRP can be based on:

  • the PDN identifier (i.e. Access Point Name or APN) the UE uses for a given connection,
  • the destination IP address the UE sends traffic to,
  • the destination port number the UE connects to, or
  • a combination of the above three elements.

Inter System Routing Policies (ISRP) Example

3GPP Inter System Routing Policies
The example shows how an operator policy can be as simple as policy #1 where it is only checking the destination port to determine if traffic should only be allowed on 3GPP – for example, VoIP data traffic. And the same framework allows an operator to define a more complicated policy such as policy #5 where two parameters – the Access Point Name (APN) and the Destination Port can be combined in a logical AND function to come up with a custom policy.

In recent years a clear trend of aggregation of the Internet traffic into few transport ports has emerged. Fewer and fewer ports carry most of the Internet traffic and in particular a very large amount of the Internet traffic is carried over port 80 (HTTP). Recent data shows that more than 50% of the total Internet traffic is carried over port 80 of various types such as web browsing, video streaming, email, and application data.

These trends impact the 3GPP Release 10 ANDSF and ISRP framework discussed in the previous section. For example, the operator with the current framework is not able to discriminate between video streaming (e.g., and web browsing (e.g., As another example, the operator will not be able to set different policies for different applications downloaded by a mobile device from an application store unless they are designed to use different port numbers.

3GPP Release 11

Given the limitations analyzed in the previous section, there is a need to more clearly identify the traffic to which a given ISRP applies. Operators can benefit significantly if they can identify a subset of traffic which has specific characteristics (e.g., video streaming) but shares the same port number characteristics of other types of traffic (e.g., port 80 for HTTP traffic).

Some ways of identifying traffic independent of destination IP and port are:

  • IP flow throughput. All IP flows that generate more than a given throughput threshold (e.g., 1 Mbps) should be handled in a certain way (e.g., Wi-Fi preferred).
  • File size. In some situations a file download is anticipated by a protocol where the file size of the download is provided by the server to the client. FTP is an example of this case, but some podcast synchronization applications which run over HTTP have this property as well. In this case, it could be possible for the operator to guide the UE to download (or upload) large files only in a given network or location.
  • Application name or identifier. The name or an identifier of the application which generates a given IP flow can be used to identify the traffic. This cannot be a general solution which applies to all applications but can be used by well-known applications or operator-provided applications (e.g., an audio streaming application which is pre-loaded in an operator phone).
  • Role identifier. Similarly, an abstraction of the characteristics of the application could be used. We refer to it as the “role” of the application and can be, for example “VoIP,” “Video Streaming,” etc. This role can be either inferred by the entity in the UE which enforces the routing decision or can be provided via an API by the application.
  • FQDN. Instead of using the destination IP address, the destination FQDN can be used. This would allow a simpler configuration and would allow having a common set of policies even in case there are a set of distributed web servers (CDNs).


  • 3GPP TS 23.261 v10.1.0 (2010-09), “IP flow mobility and seamless Wireless Local Area Network (WLAN) offload; Stage 2”.
  • 3GPP TR 23.855 v0.1.0 (2011-04), “Data identification in ANDSF”.
  • 3GPP TS 24.312 v10.2.1 (2011-04), “Access Network Discovery and Selection Function (ANDSF) Management Object (MO)”.
  • 3GPP TS 23.402 v10.3.0 (2011-03), “Architecture enhancements for non-3GPP accesses”.