Two high items in the news last week caught my attention. The first was the Q3 earnings report from Motorola. As a former employee, I still have more than a passing interest in Motorola’s performance. Third-quarter sales of US $5.8 Billion were up year-over-year - the first growth quarter since fourth quarter of 2006. Net earnings in the third quarter of 2010 were $109 million. So Motorola is profitable.
Looking a little bit closer, the Mobile Devices division had sales of $2.0 billion that including shipping 9.1 million handsets, of which 3.8 million were smartphones. In fact a total of 22 smartphones were introduced by Motorola during 2010. Overall that yielded the division a GAAP operating loss of $43 million. But how did they stack up against Apple's iPhone sales?
In Q3, compared to Motorola's 3.8 million smartphones, Apple shipped 14.1 million iPhones up 90% from the same period last year when 7.4 million units were sold. According to International Data Corporation (IDC) Worldwide Mobile Phone Tracker, this has propelled Apple to number 4 mobile phone vendor in terms of market share comprising 4.1% of the market. The top 3 are Nokia, Samsung and LG with 32.4%, 21% and 8.3% market share respectively. During my time at Motorola from 1999 to 2007, the former market leader was mostly #2 with market share ranging from 10%-20%.
So in conclusion, while Motorola's handset division may have finally turned the corner, with a market share of approximately 2.7%, Motorola still has a lot of catching up to do on its rivals.
Monday, November 1, 2010
Friday, October 22, 2010
4G Self-Organizing/Optimization Networks (SON)
Last week I found the 4G Self-Organizing/Optimization Networks (SON) group on LinkedIn. I was browsing through some of the discussions. Lots of interesting information posted here but one document in particular did catch my eye: The Benefits of SON in LTE from 3G Americas December 2009.
The idea of self-organising networks is great - in principle, but when you start asking what self-organising capability do you mean exactly then this is where it starts getting a bit more tricky. That's when you need to start getting into the business logic. In an ideal world, you might like it to mean fully automated with no manual intervention required, but when you are coming from an environment where most configuration processes involve some element, if not all, of manual intervention then you need to start defining exactly which processes can be automated.
That's where the above article gets interesting. It introduces the technology and market drivers for SON and the reasons for automation. Then it describes the key LTE Release 8 and Release 9 SON features as defined by 3GPP including how they can be supported and what the benefits are. These include:
The idea of self-organising networks is great - in principle, but when you start asking what self-organising capability do you mean exactly then this is where it starts getting a bit more tricky. That's when you need to start getting into the business logic. In an ideal world, you might like it to mean fully automated with no manual intervention required, but when you are coming from an environment where most configuration processes involve some element, if not all, of manual intervention then you need to start defining exactly which processes can be automated.
That's where the above article gets interesting. It introduces the technology and market drivers for SON and the reasons for automation. Then it describes the key LTE Release 8 and Release 9 SON features as defined by 3GPP including how they can be supported and what the benefits are. These include:
- Base Station Self-Configuration
- Automatic Neighbour Relations
- Tracking Area Planning
- PCI Planning
- Load Balancing
- Mobility Robustness / Handover Optimisation
Wednesday, October 13, 2010
Wireless Network Optimisation
Following on from my last post on monitoring network performance, I attended a webinar called Wireless Network Optimisation from Alcatel-Lucent. It outlined some of the main concerns for a wireless network operator once a network is deployed, although this really boils down to just one thing: How can the bottom line be improved from the exiting network infrastructure? The answer is to optimise the network configuration. The webinar described a 4-step methodology for network optimisation:
How big is this business for Alcatel-Lucent? According to their Q2 2010 Earnings Report, in the quarter Alcatel-Lucent had total revenues of €3.813 billion and a net loss of €183 million. The Services division had revenues of €883 million, making a profit €19 million in Q2. In the webinar, Alcatel-Lucent stated that have 60 optimisation tools built in-house and another 20 co-developed with Bell-Labs. They have 800+ design and optimisation experts to perform the work for their 250+ customers.
I think this gives a picture of the scale the business, but also an idea that once the network equipment is purchased and installed, the work if far from done. It should come as no surprise then that the network operators, the customers for the network equipment vendors such as Alcatel-Lucent, would desire that the vendors bring to markets network equipment that are capable of Self-Organising Networks (SON).
- End-to-End Audit. Collect data from the network such as network topology capture or performance monitoring.
- Traffic Profile Analysis. Correlating current network capacity and projected traffic forecasting.
- Recommendation. Develop a new planned configuration change.
- Execution. Deploy and activate the new network configuration.
How big is this business for Alcatel-Lucent? According to their Q2 2010 Earnings Report, in the quarter Alcatel-Lucent had total revenues of €3.813 billion and a net loss of €183 million. The Services division had revenues of €883 million, making a profit €19 million in Q2. In the webinar, Alcatel-Lucent stated that have 60 optimisation tools built in-house and another 20 co-developed with Bell-Labs. They have 800+ design and optimisation experts to perform the work for their 250+ customers.
I think this gives a picture of the scale the business, but also an idea that once the network equipment is purchased and installed, the work if far from done. It should come as no surprise then that the network operators, the customers for the network equipment vendors such as Alcatel-Lucent, would desire that the vendors bring to markets network equipment that are capable of Self-Organising Networks (SON).
Monday, October 11, 2010
Monitoring IP Traffic
Monitoring the performance of the network is essential for an operator to verify that the network is performing as expected and also to identify new configuration changes in order to optimise the network configuration. For example, mobile network operators gather millions of raw statistics 24/7 365 days a year. The statistics are used to calculate Key Performance Indicators (KPIs) that quantify the network performance and to determine an improved planned configuration.
For IP networks, many tools are available for collecting performance data from the network which itself can be problematic. An enterprise may undertake to develop its own bespoke management system that integrates the tools it wants to use to monitor the performance of the network, or purchase off-the shelf tools from a vendor that may have already integrated some 3rd party tools. Integation of the tools is one thing, how you visual the information is another.
Last week, I become aware of one such tool, DangNetworks that uses SNMP and NetFlow that can, according to its website, "Monitor saturated links with SNMP, and find out who's causing it with NetFlow". Through using the two mechanisms together, an network operator can derive more value with what's going on in the network. Afterall what's of primary importance to an operator or enterprise manager is that the services or applications that are of most value to their business are performing as expected.
While the number of monitoring tools available continues to grow, it should be noted that collecting large volumes of network performance data can in itself degrade network performance so for the network operator, monitoring the network is a balancing act.
One aspect of the work that we are undertaking in EFIPSANS is that performance monitoring of the network can be set at a minimal level under normal operating conditions. Through monitoring of certain metrics, the performance level can be autonomously adjusted to gather more data to determine the reason for a performance degradation than can ultimately result in a self-configuration of the network. Normal performance monitoring can be restored once the criteria of normal operating conditions have been met.
We developed a tool for path monitoring, called a Path Management Element, for monitoring the performance of a path. For example, if the PathME detects that the latency for a particular flow has exceeded a predetermined threshold at an endpoint, the PathME can turn on additional monitoring along the path from the source to destination to identify where the latency is being incurred along the path.
The PathME integrates tools such as ping and traceroute to measure the performance of a path. We have also developed an experimental intrinsic monitoring protocol, that uses the Router Alert feature as defined by RFC 2711, that is able to collect performance metrics in-line at each node in a Hop-By-Hop manner as a packet traverses the network along a path. This is currently being integrated into the PathME, as is support for One Way Active Measurement Protocol (OWAMP), defined by RFC 4656, and IP Flow Information Export (IPFIX), defined by RFC 3917.
The PathME uses a common model that defines the managed objects, their attributes and relationships that are supported for a path. The user of the PathME can customise what performance information is required, and how often a measurement report should be generated. The PathME uses a mediation function to abstract the actual tools used to collect the data. The performance report is an XML file that complies with the XML schema that describes the common model.
The intrinisic monitoring aspect of this work will be presented at CNSM 2010 later this month at Niagara Falls, Canada.
For IP networks, many tools are available for collecting performance data from the network which itself can be problematic. An enterprise may undertake to develop its own bespoke management system that integrates the tools it wants to use to monitor the performance of the network, or purchase off-the shelf tools from a vendor that may have already integrated some 3rd party tools. Integation of the tools is one thing, how you visual the information is another.
Last week, I become aware of one such tool, DangNetworks that uses SNMP and NetFlow that can, according to its website, "Monitor saturated links with SNMP, and find out who's causing it with NetFlow". Through using the two mechanisms together, an network operator can derive more value with what's going on in the network. Afterall what's of primary importance to an operator or enterprise manager is that the services or applications that are of most value to their business are performing as expected.
While the number of monitoring tools available continues to grow, it should be noted that collecting large volumes of network performance data can in itself degrade network performance so for the network operator, monitoring the network is a balancing act.
One aspect of the work that we are undertaking in EFIPSANS is that performance monitoring of the network can be set at a minimal level under normal operating conditions. Through monitoring of certain metrics, the performance level can be autonomously adjusted to gather more data to determine the reason for a performance degradation than can ultimately result in a self-configuration of the network. Normal performance monitoring can be restored once the criteria of normal operating conditions have been met.
We developed a tool for path monitoring, called a Path Management Element, for monitoring the performance of a path. For example, if the PathME detects that the latency for a particular flow has exceeded a predetermined threshold at an endpoint, the PathME can turn on additional monitoring along the path from the source to destination to identify where the latency is being incurred along the path.
The PathME integrates tools such as ping and traceroute to measure the performance of a path. We have also developed an experimental intrinsic monitoring protocol, that uses the Router Alert feature as defined by RFC 2711, that is able to collect performance metrics in-line at each node in a Hop-By-Hop manner as a packet traverses the network along a path. This is currently being integrated into the PathME, as is support for One Way Active Measurement Protocol (OWAMP), defined by RFC 4656, and IP Flow Information Export (IPFIX), defined by RFC 3917.
The PathME uses a common model that defines the managed objects, their attributes and relationships that are supported for a path. The user of the PathME can customise what performance information is required, and how often a measurement report should be generated. The PathME uses a mediation function to abstract the actual tools used to collect the data. The performance report is an XML file that complies with the XML schema that describes the common model.
The intrinisic monitoring aspect of this work will be presented at CNSM 2010 later this month at Niagara Falls, Canada.
Thursday, September 23, 2010
AutoI Completes Final Review
Last week I was in Brussels attending the FP7 project AutoI project final technical review. This was a 2.5 year project co-ordinated by Hitachi. The other partners in the consortium were Waterford Institute of Technology, Lip6, Universitat Politecnica de Catalunya, Gingko Networks, University College of London, INRIA, University of Passau, University of Patras, Ucopia and Motorola.
The primary objective of the project was to research novel mechanisms that would enable service-based resource orchestration for virtualised networked. Or put another way, the autonomic provisioning of a virtualised network based on the requirements of a service. Based on the demands on the service, the virtualised resources can be self-optimised by adding or removing virtual resources or even moving virtual resources.
As well as representing the project, as workpackage leader I was presenting the result of Workpackage 3 Information Modelling. The objective of this workpackage was primarily to define a model that all the architectural components developed within AutoI would use to communicate with each other as well as providing a level of abstraction by hiding the heterogenous nature of the network and the vendor-specific data models. The model was supplemented by ontologies that augmented the model to support inferencing and reasoning. For example, if an alarm is reported for a specific network interface, what is the impact on the customer facing service? Is this somehing that an operator should be immediately concerned about? WP3 developed a Model Based Translator to perform the mediation. This is available as open source from the project website and already has been extended in EFIPSANS FP7 project which is still ongoing.
The project has now successfully concluded and I would like to thank the partners for their fruitful collaboration.
The primary objective of the project was to research novel mechanisms that would enable service-based resource orchestration for virtualised networked. Or put another way, the autonomic provisioning of a virtualised network based on the requirements of a service. Based on the demands on the service, the virtualised resources can be self-optimised by adding or removing virtual resources or even moving virtual resources.
As well as representing the project, as workpackage leader I was presenting the result of Workpackage 3 Information Modelling. The objective of this workpackage was primarily to define a model that all the architectural components developed within AutoI would use to communicate with each other as well as providing a level of abstraction by hiding the heterogenous nature of the network and the vendor-specific data models. The model was supplemented by ontologies that augmented the model to support inferencing and reasoning. For example, if an alarm is reported for a specific network interface, what is the impact on the customer facing service? Is this somehing that an operator should be immediately concerned about? WP3 developed a Model Based Translator to perform the mediation. This is available as open source from the project website and already has been extended in EFIPSANS FP7 project which is still ongoing.
The project has now successfully concluded and I would like to thank the partners for their fruitful collaboration.
Tuesday, August 31, 2010
Fault Tolerant Design Methodology
In my recent post, Fault Tolerant Management, I discussed a project proposal with the objective of defining a methodology for engineering stable and reliable self-* managment systems. One of the inspirations for this came from an interview by Robert S. Hamner that I had heard a few years ago on Software Engineering Radio Episode 77: Fault Tolerance with Bob Hanmer Part 1. There had been a lot of previous research covering various aspects of self-* management systems. Telecoms systems usually have high availability requirements, however, this is not necessarily the case for the management systems. It reasonable to expect that self-* management would be capable of operating independently, making decisions, detecting and recovering from failures - both to itself and to the network its managing.
One aspect of the project was to look at engineering techniques to accelerate migration from the typical legacy centralised management systems toward fault-tolerant self-* management systems. As I worked as System Engineer designing management systems for mobile networks, I was very interested in what Bob had say. His book Patterns for Fault Tolerant Software, which I'm reading at the moment, identifies patterns for each of the four phases of fault tolerance:
Chapter 2 of the book introduces the Fault Tolerant Mindset where throughout the architecture design you should always be asking what can wrong! Not always easy for large systems that must perform a multitude of task concurrently. Chapter 2 concludes by outlining a fault tolerant design methodology. I'm finding the book very interesting and thought provoking so far and am looking forward to completing the rest of it.
One aspect of the project was to look at engineering techniques to accelerate migration from the typical legacy centralised management systems toward fault-tolerant self-* management systems. As I worked as System Engineer designing management systems for mobile networks, I was very interested in what Bob had say. His book Patterns for Fault Tolerant Software, which I'm reading at the moment, identifies patterns for each of the four phases of fault tolerance:
- Error Detection
- Error Processing including Error Recovery
- Error Mitigation
- Fault Treatment
Chapter 2 of the book introduces the Fault Tolerant Mindset where throughout the architecture design you should always be asking what can wrong! Not always easy for large systems that must perform a multitude of task concurrently. Chapter 2 concludes by outlining a fault tolerant design methodology. I'm finding the book very interesting and thought provoking so far and am looking forward to completing the rest of it.
Tuesday, August 24, 2010
3GPP SON Concepts and Requirements
August can be a quiet month on the project front. Its especially true on collaborative projects when partners tend to take vacation so organising project meetings involving all participants can prove to be difficult indeed. I find it a good time to take stock, and reflect on how the year is progressing and take the opportunity for a "heads up" to see what else is going on.
I've been doing just that, and have been taking a look at the latest developments in 3GPP or specifically the Self-Organising Networks (SON) specifications. I started with the TS 32.500 specification for Release 10 "Concepts and Requirements". Even for Release 10, you get the feeling that the requirements are only scratching the surface of what really is required to make SON a reality. Let's take a look at the business level requirements and assess the impact of them.
REQ-SON-CON-01 SON solutions shall provide an easy transition from operator controlled (open loop) to autonomous (closed loop) operation, as the network operator gains more trust in the reliability of the SON
The very first requirement hits on probably most difficult requirement of all. Can SON ever be delivered reliably? Well if it cannot, we may as well not go any further. What would be the point of SON if it wasn't reliable. As far as network management practices go, where network configuration was traditionally carefully planned and pushed out into the network in a controlled manner, the idea that a SON function can identify the changes and activate them automatically is a huge paradigm shift. The likelyhood is that introducing SON will be in the form of baby steps, and this requirement provides the training wheels.
REQ-SON-CON-02 The SON Architecture and implementation should support network sharing between network operators. The impact of individual shared network topographies on proposed SON solutions shall be decided on a case-by-case basis.
Network sharing is one method of reducing operating costs, so it comes as no surprise to see this here. How is it going to work though? It will require a bit of thought where traditionally the network operator planning personnel determined the network configuration to be deployed.
REQ-SON-CON-05 For operator controlled (open loop) SON function, the implementation of any update proposed by the SON function shall take effect only after a response by the Operator.
This is related to the first requirement providing the operator with the final say on whether the proposed configuration change from the SON application should be applied.
REQ-SON-CON-06 For closed loop SON function, the implementation of any update proposed by the SON function shall take effect without the need for response by the Operator
This goes without saying. It truely is SON, a simple and straightforward requirement with significant implications. What if the update proposed is incorrect and causes network performance degradation or worse, a network outage?
REQ-SON-CON-07 An NE can operate with SON function or without SON function and can easily be transferred between these two modes. The ability to suspend/ resume/ enable/ disable the SON function shall be determined on a case by case basis.
In otherwords, if the SON functions are not performing as hoped, lets turn it off and go back to managing the Network Element as before.
These are the general requirements defined for SON thus far. Granted it is early days and I would anticipate some changes. As you can see, these requirements are mostly defensive in nature and aimed to facilitate the operator in letting go of control, somewhat similiar to a parent reluctantly letting a child making their own way in the world.
I've been doing just that, and have been taking a look at the latest developments in 3GPP or specifically the Self-Organising Networks (SON) specifications. I started with the TS 32.500 specification for Release 10 "Concepts and Requirements". Even for Release 10, you get the feeling that the requirements are only scratching the surface of what really is required to make SON a reality. Let's take a look at the business level requirements and assess the impact of them.
REQ-SON-CON-01 SON solutions shall provide an easy transition from operator controlled (open loop) to autonomous (closed loop) operation, as the network operator gains more trust in the reliability of the SON
The very first requirement hits on probably most difficult requirement of all. Can SON ever be delivered reliably? Well if it cannot, we may as well not go any further. What would be the point of SON if it wasn't reliable. As far as network management practices go, where network configuration was traditionally carefully planned and pushed out into the network in a controlled manner, the idea that a SON function can identify the changes and activate them automatically is a huge paradigm shift. The likelyhood is that introducing SON will be in the form of baby steps, and this requirement provides the training wheels.
REQ-SON-CON-02 The SON Architecture and implementation should support network sharing between network operators. The impact of individual shared network topographies on proposed SON solutions shall be decided on a case-by-case basis.
Network sharing is one method of reducing operating costs, so it comes as no surprise to see this here. How is it going to work though? It will require a bit of thought where traditionally the network operator planning personnel determined the network configuration to be deployed.
REQ-SON-CON-05 For operator controlled (open loop) SON function, the implementation of any update proposed by the SON function shall take effect only after a response by the Operator.
This is related to the first requirement providing the operator with the final say on whether the proposed configuration change from the SON application should be applied.
REQ-SON-CON-06 For closed loop SON function, the implementation of any update proposed by the SON function shall take effect without the need for response by the Operator
This goes without saying. It truely is SON, a simple and straightforward requirement with significant implications. What if the update proposed is incorrect and causes network performance degradation or worse, a network outage?
REQ-SON-CON-07 An NE can operate with SON function or without SON function and can easily be transferred between these two modes. The ability to suspend/ resume/ enable/ disable the SON function shall be determined on a case by case basis.
In otherwords, if the SON functions are not performing as hoped, lets turn it off and go back to managing the Network Element as before.
REQ-SON-CON-8 An IRPManager shall be able to monitor the specific results of each particular SON function
Even if the SON function operates smoothly and is effective, there is still a need for it to be monitored, if for nothing else to re-assure the operator that automatic reconfiguration has taking place and how often.These are the general requirements defined for SON thus far. Granted it is early days and I would anticipate some changes. As you can see, these requirements are mostly defensive in nature and aimed to facilitate the operator in letting go of control, somewhat similiar to a parent reluctantly letting a child making their own way in the world.
Subscribe to:
Comments (Atom)