By Frank Bulk
Aruba Networks most recent announcement regarding NAC interoperability verification and a product announcement repeat a common anthem of this vendor's emphasis on security.
The three major NAC groups are Cisco, Microsoft NAP, and the Trusted Computing Group (TCG); the first two are clearly vendor driven, while the last is standards-based and enjoys broader industry support. Unable to drive a standard of its own, Aruba has not hitched itself to any single group, but has verified NAC interoperability with three technology industry heavyweights: Cisco, Juniper, and Microsoft. Working with network equipment market share leader Cisco is almost a de facto requirement, and Microsoft is Aruba's largest customer, if not most significant. This shouldn't be considered Aruba's first fore into NAC: they have partnerships with Bradford, FireEye, Fortinet, InfoExpress, Snort, and as well as Symantec (via Sygate, though this is end-of-sale).
In addition to their partnerships, Aruba has also announced a new appliance for "targeted industries". To date Aruba has built most of the products it sells, preferring to partner where necessary. Ash Chowdappa, director of mobility management system, stated in a briefing, that Aruba will wait until the NAC market shakes out before considering to develop something internally. This time around Aruba OEMed their Aruba Endpoint Compliance System (ECS) appliance from a vendor that has significant success in the higher education market.According to Chowdappa, higher education is Aruba's number one vertical, and they expect ECS to gain traction in healthcare and hospitality, markets where there are significant numbers of guest users. Aruba makes the point that many NAC vendors are targeted toward managed devices such as desktops and laptops, while ECS is able to deal with unmanaged and transient devices such as Vo-Fi phones, and the occasional Sony Wii, that may not be able to run an agent. For devices in this latter group Aruba's ECS can work in tandem with their mobility controller to implement more restrictive traffic policies leveraging Aruba's stateful firewall. And this appliance isn't restricted to just wireless products, as the appliance can take trunked wired traffic, such as guest VLANs, and enforce policy on those, too.
Aruba is making the right moves in offering its customers multiple NAC options resulting in great stickiness for their core wireless LAN products. One of the challenges that Aruba faces is that organizations may look first to their wired networking equipment vendor for a NAC product, giving Cisco a natural leg up. Aruba appears to have chosen to OEM a mature product that integrates with systems in both mediums, and with eventual implementation of 802.11n, may take a larger and larger portion of IT's mindshare and networking budget.
Thursday, 13 March 2008
Aruba secures endpoints with NAC interop and product.
Aruba secures endpoints with NAC interop and product.
By Frank Bulk
Aruba Networks most recent announcement regarding NAC interoperability verification and a product announcement repeat a common anthem of this vendor's emphasis on security.
The three major NAC groups are Cisco, Microsoft NAP, and the Trusted Computing Group (TCG); the first two are clearly vendor driven, while the last is standards-based and enjoys broader industry support. Unable to drive a standard of its own, Aruba has not hitched itself to any single group, but has verified NAC interoperability with three technology industry heavyweights: Cisco, Juniper, and Microsoft. Working with network equipment market share leader Cisco is almost a de facto requirement, and Microsoft is Aruba's largest customer, if not most significant. This shouldn't be considered Aruba's first fore into NAC: they have partnerships with Bradford, FireEye, Fortinet, InfoExpress, Snort, and as well as Symantec (via Sygate, though this is end-of-sale).
In addition to their partnerships, Aruba has also announced a new appliance for "targeted industries". To date Aruba has built most of the products it sells, preferring to partner where necessary. Ash Chowdappa, director of mobility management system, stated in a briefing, that Aruba will wait until the NAC market shakes out before considering to develop something internally. This time around Aruba OEMed their Aruba Endpoint Compliance System (ECS) appliance from a vendor that has significant success in the higher education market.According to Chowdappa, higher education is Aruba's number one vertical, and they expect ECS to gain traction in healthcare and hospitality, markets where there are significant numbers of guest users. Aruba makes the point that many NAC vendors are targeted toward managed devices such as desktops and laptops, while ECS is able to deal with unmanaged and transient devices such as Vo-Fi phones, and the occasional Sony Wii, that may not be able to run an agent. For devices in this latter group Aruba's ECS can work in tandem with their mobility controller to implement more restrictive traffic policies leveraging Aruba's stateful firewall. And this appliance isn't restricted to just wireless products, as the appliance can take trunked wired traffic, such as guest VLANs, and enforce policy on those, too.
Aruba is making the right moves in offering its customers multiple NAC options resulting in great stickiness for their core wireless LAN products. One of the challenges that Aruba faces is that organizations may look first to their wired networking equipment vendor for a NAC product, giving Cisco a natural leg up. Aruba appears to have chosen to OEM a mature product that integrates with systems in both mediums, and with eventual implementation of 802.11n, may take a larger and larger portion of IT's mindshare and networking budget.
Aruba secures endpoints with NAC interop and product.
By Frank Bulk
Aruba Networks most recent announcement regarding NAC interoperability verification and a product announcement repeat a common anthem of this vendor's emphasis on security.
The three major NAC groups are Cisco, Microsoft NAP, and the Trusted Computing Group (TCG); the first two are clearly vendor driven, while the last is standards-based and enjoys broader industry support. Unable to drive a standard of its own, Aruba has not hitched itself to any single group, but has verified NAC interoperability with three technology industry heavyweights: Cisco, Juniper, and Microsoft. Working with network equipment market share leader Cisco is almost a de facto requirement, and Microsoft is Aruba's largest customer, if not most significant. This shouldn't be considered Aruba's first fore into NAC: they have partnerships with Bradford, FireEye, Fortinet, InfoExpress, Snort, and as well as Symantec (via Sygate, though this is end-of-sale).
In addition to their partnerships, Aruba has also announced a new appliance for "targeted industries". To date Aruba has built most of the products it sells, preferring to partner where necessary. Ash Chowdappa, director of mobility management system, stated in a briefing, that Aruba will wait until the NAC market shakes out before considering to develop something internally. This time around Aruba OEMed their Aruba Endpoint Compliance System (ECS) appliance from a vendor that has significant success in the higher education market.According to Chowdappa, higher education is Aruba's number one vertical, and they expect ECS to gain traction in healthcare and hospitality, markets where there are significant numbers of guest users. Aruba makes the point that many NAC vendors are targeted toward managed devices such as desktops and laptops, while ECS is able to deal with unmanaged and transient devices such as Vo-Fi phones, and the occasional Sony Wii, that may not be able to run an agent. For devices in this latter group Aruba's ECS can work in tandem with their mobility controller to implement more restrictive traffic policies leveraging Aruba's stateful firewall. And this appliance isn't restricted to just wireless products, as the appliance can take trunked wired traffic, such as guest VLANs, and enforce policy on those, too.
Aruba is making the right moves in offering its customers multiple NAC options resulting in great stickiness for their core wireless LAN products. One of the challenges that Aruba faces is that organizations may look first to their wired networking equipment vendor for a NAC product, giving Cisco a natural leg up. Aruba appears to have chosen to OEM a mature product that integrates with systems in both mediums, and with eventual implementation of 802.11n, may take a larger and larger portion of IT's mindshare and networking budget.
Monday, 3 March 2008
Checklist for Planning a Voice Over Wi-Fi Network: Security and Performance
While Wi-Fi offers a number of different security options, many voice handsets only support a subset because of processing, cost and battery considerations. Therefore design of a WLAN for voice may entail compromising over-the-air security to accommodate available handsets. We believe the correct approach is as below: first choose a handset, then see if it can support the desired security model (the goal should be that voice and data work at the same level, e.g. WPA2/802.1x). If the handset cannot attain this level, the network designer should take steps to make sure that they can be allowed onto the network, but that special security measures prevent intruders from posing as voice clients to hack into the network, as explained below.
First, identify the desired handset or range of handsets. This is a general rule for adding voice services: start with the handset. Choice is often based on factors such as durability, aesthetics, PBX features supported, voice & data capabilities.
Now examine the security capabilities. While a few months ago many handsets were limited to WEP security, a new generation is now available and the network designer should aim for WPA/PSK as a minimum level of security. WPA2 is better, with WPA2/802.1x preferable to WPA2PSK, but performance, particularly handover performance will suffer as more sophisticated security is used. We favour Opportunistic Key Caching (OKC) with WPA2 for excellent security with fast handover.
Good security design requires a comprehensive approach, so it is important to examine other aspects of the network. Many networks use a separate VLAN to segregate voice traffic, although VLANs are not a good security tool and converged voice/data clients cannot be accommodated with this model.
Other approaches involve using firewall functionality to identify and police voice traffic, particularly when the voice handsets cannot offer the same level of authentication/encryption as Wi-Fi data clients. This is obviously Aruba’s approach, as we have an integrated, Wi-Fi aware firewall.
At Aruba, we have found that re-keying in an 802.1x network can stress a handset’s processor to the degree that it can interrupt voice calls. Therefore we now have a feature that delays re-keying till the handset is idle (not on a call). An alternative, but inferior approach is to use a longer re-keying interval for voice devices.
Handover performance
Handing over a voice call from AP to AP is a function of both the infrastructure and the client. While handover latency can be measured under laboratory conditions, there are many additional factors that affect real-life performance.
The target figure for interruptions in a voice call due to handover is 50-100 msec: at these levels the user will not notice the interruption. The state-of-the-art for lab tests is sub-20 msec.
Attention to AP spacing and RF planning as explained above will help to ensure that field experience is close to lab experience.
Security determines handover performance. Pre-shared keys allow much faster handover than 802.1x environments, although of course they are not as secure. There is not much inherent performance difference between WPA and WPA2 encryption levels, except that the latter requires more processing on the handset.
The ideal balance of security and performance today is when WPA2 is used with 802.1x and ‘opportunistic key caching’ in a centralised-controller WLAN.
802.11r is a new standard, intended to improve handover performance. In centralised WLAN architectures such as Aruba’s it offers only limited improvements, particularly if opportunistic key caching is used (see above). But 802.11r support should be on the checklist for the WLAN vendor.
Battery Life
Good battery life is an important usability consideration for voice-over-Wi-Fi installations. While much battery-saving technology depends on the handset, there are a variety of functions where the infrastructure can assist in extending battery life.
Determine desired battery life: this will depend on applications. For retail and hospital environments, where people pick up their phone in the morning or at the beginning of their shift, and return it to a charging cradle at the end of the day, a battery life of 12 hours may be adequate. This is quite easily achievable today.
However, a dual-mode cellular/Wi-Fi phone will be treated more like a cellphone, where users expect multiple days between charges. Performance is improving rapidly, but currently most dual-mode phones’ batteries will barely last for 24 hours with heavy business use. Handset vendors and WLAN infrastructure vendors, including Aruba, are innovating in this area.
U-APSD (Unscheduled, Asynchronous Power Save Delivery) is part of the 802.11e specification that the Wi-Fi Alliance is certifying as WMM-PS (Wireless MultiMedia Power Save). This offers considerable improvement in battery life over former protocols, and while few handsets support U-APSD today, any new Wi-Fi infrastructure must be U-APSD/WMM-PS capable.
ARP proxy. The key to extending battery life, particularly idle (not on-call) battery life is to reduce the LAN traffic the handset sees. The most significant type of traffic is ARP’s, and good WLANs now proxy to reduce this traffic to voice clients.
Traffic filtering. Some vendors offer features where extraneous traffic is not delivered to voice clients, thus saving the battery drain entailed in receiving and ack’ing such traffic. Many types of multicast fall into this category.
• Other features. Battery life is one of the few areas in voice-over-Wi-Fi where the standards (and drafts of future standards) are not sufficient for good performance. Therefore the customers should expect ‘proprietary’ extensions to standards in this area. Some of these require compatible clients, whereas others work with standard clients. At Aruba we have several of these, so please check with us and our competitors about the state of the standards and the state-of-the-art.
Wi-Fi Alliance Certifications
The Wi-Fi vendors and other interested parties take standards developed and published by the IEEE 802.11 committee, but most vendors today tend to develop to certifications of the Wi-Fi Alliance, a group of vendors formed to develop the market for 802.11 (and the originator of the term ‘Wi-Fi’, Wi-Fi logos, etc). Wi-Fi Alliance certifications are nearly all derived from subsets of the IEEE standards, and result in standardized tests to ensure inter-vendor interoperability. The notes above identify the most important certifications, but they are re-stated below (this is a subjective rather than a complete list: these are most relevant to voice-over-Wi-Fi infrastructure for Enterprise). In selecting a WLAN vendor, it is more practical to ask for a roadmap for these certifications rather than references to IEEE standards.
Security certifications relevant to voice to include WPA and WPA2, which are derived from 802.11i.
WMM (Wireless MultiMedia) defines over-the-air QoS from subsets of 802.11e.
WMM-PS (Wireless MultiMedia Power Save) includes U-APSD from 802.11e.
WMM-AC (Access Control) is not yet finished, but will include T-Spec signalling from 802.11e for Call Admissions Control.
‘Voice over Wi-Fi for Enterprise’ (name may change) will include parts of 802.11e, 802.11k, 802.11r and others in an attempt to ensure good performance and inter-vendor interoperability in Enterprise networks with multiple APs and other Enterprise requirements.
Checklist for Planning a Voice Over Wi-Fi Network: Security and Performance
While Wi-Fi offers a number of different security options, many voice handsets only support a subset because of processing, cost and battery considerations. Therefore design of a WLAN for voice may entail compromising over-the-air security to accommodate available handsets. We believe the correct approach is as below: first choose a handset, then see if it can support the desired security model (the goal should be that voice and data work at the same level, e.g. WPA2/802.1x). If the handset cannot attain this level, the network designer should take steps to make sure that they can be allowed onto the network, but that special security measures prevent intruders from posing as voice clients to hack into the network, as explained below.
First, identify the desired handset or range of handsets. This is a general rule for adding voice services: start with the handset. Choice is often based on factors such as durability, aesthetics, PBX features supported, voice & data capabilities.
Now examine the security capabilities. While a few months ago many handsets were limited to WEP security, a new generation is now available and the network designer should aim for WPA/PSK as a minimum level of security. WPA2 is better, with WPA2/802.1x preferable to WPA2PSK, but performance, particularly handover performance will suffer as more sophisticated security is used. We favour Opportunistic Key Caching (OKC) with WPA2 for excellent security with fast handover.
Good security design requires a comprehensive approach, so it is important to examine other aspects of the network. Many networks use a separate VLAN to segregate voice traffic, although VLANs are not a good security tool and converged voice/data clients cannot be accommodated with this model.
Other approaches involve using firewall functionality to identify and police voice traffic, particularly when the voice handsets cannot offer the same level of authentication/encryption as Wi-Fi data clients. This is obviously Aruba’s approach, as we have an integrated, Wi-Fi aware firewall.
At Aruba, we have found that re-keying in an 802.1x network can stress a handset’s processor to the degree that it can interrupt voice calls. Therefore we now have a feature that delays re-keying till the handset is idle (not on a call). An alternative, but inferior approach is to use a longer re-keying interval for voice devices.
Handover performance
Handing over a voice call from AP to AP is a function of both the infrastructure and the client. While handover latency can be measured under laboratory conditions, there are many additional factors that affect real-life performance.
The target figure for interruptions in a voice call due to handover is 50-100 msec: at these levels the user will not notice the interruption. The state-of-the-art for lab tests is sub-20 msec.
Attention to AP spacing and RF planning as explained above will help to ensure that field experience is close to lab experience.
Security determines handover performance. Pre-shared keys allow much faster handover than 802.1x environments, although of course they are not as secure. There is not much inherent performance difference between WPA and WPA2 encryption levels, except that the latter requires more processing on the handset.
The ideal balance of security and performance today is when WPA2 is used with 802.1x and ‘opportunistic key caching’ in a centralised-controller WLAN.
802.11r is a new standard, intended to improve handover performance. In centralised WLAN architectures such as Aruba’s it offers only limited improvements, particularly if opportunistic key caching is used (see above). But 802.11r support should be on the checklist for the WLAN vendor.
Battery Life
Good battery life is an important usability consideration for voice-over-Wi-Fi installations. While much battery-saving technology depends on the handset, there are a variety of functions where the infrastructure can assist in extending battery life.
Determine desired battery life: this will depend on applications. For retail and hospital environments, where people pick up their phone in the morning or at the beginning of their shift, and return it to a charging cradle at the end of the day, a battery life of 12 hours may be adequate. This is quite easily achievable today.
However, a dual-mode cellular/Wi-Fi phone will be treated more like a cellphone, where users expect multiple days between charges. Performance is improving rapidly, but currently most dual-mode phones’ batteries will barely last for 24 hours with heavy business use. Handset vendors and WLAN infrastructure vendors, including Aruba, are innovating in this area.
U-APSD (Unscheduled, Asynchronous Power Save Delivery) is part of the 802.11e specification that the Wi-Fi Alliance is certifying as WMM-PS (Wireless MultiMedia Power Save). This offers considerable improvement in battery life over former protocols, and while few handsets support U-APSD today, any new Wi-Fi infrastructure must be U-APSD/WMM-PS capable.
ARP proxy. The key to extending battery life, particularly idle (not on-call) battery life is to reduce the LAN traffic the handset sees. The most significant type of traffic is ARP’s, and good WLANs now proxy to reduce this traffic to voice clients.
Traffic filtering. Some vendors offer features where extraneous traffic is not delivered to voice clients, thus saving the battery drain entailed in receiving and ack’ing such traffic. Many types of multicast fall into this category.
• Other features. Battery life is one of the few areas in voice-over-Wi-Fi where the standards (and drafts of future standards) are not sufficient for good performance. Therefore the customers should expect ‘proprietary’ extensions to standards in this area. Some of these require compatible clients, whereas others work with standard clients. At Aruba we have several of these, so please check with us and our competitors about the state of the standards and the state-of-the-art.
Wi-Fi Alliance Certifications
The Wi-Fi vendors and other interested parties take standards developed and published by the IEEE 802.11 committee, but most vendors today tend to develop to certifications of the Wi-Fi Alliance, a group of vendors formed to develop the market for 802.11 (and the originator of the term ‘Wi-Fi’, Wi-Fi logos, etc). Wi-Fi Alliance certifications are nearly all derived from subsets of the IEEE standards, and result in standardized tests to ensure inter-vendor interoperability. The notes above identify the most important certifications, but they are re-stated below (this is a subjective rather than a complete list: these are most relevant to voice-over-Wi-Fi infrastructure for Enterprise). In selecting a WLAN vendor, it is more practical to ask for a roadmap for these certifications rather than references to IEEE standards.
Security certifications relevant to voice to include WPA and WPA2, which are derived from 802.11i.
WMM (Wireless MultiMedia) defines over-the-air QoS from subsets of 802.11e.
WMM-PS (Wireless MultiMedia Power Save) includes U-APSD from 802.11e.
WMM-AC (Access Control) is not yet finished, but will include T-Spec signalling from 802.11e for Call Admissions Control.
‘Voice over Wi-Fi for Enterprise’ (name may change) will include parts of 802.11e, 802.11k, 802.11r and others in an attempt to ensure good performance and inter-vendor interoperability in Enterprise networks with multiple APs and other Enterprise requirements.
Checklist for Planning a Voice Over Wi-Fi Network: Security and Performance
While Wi-Fi offers a number of different security options, many voice handsets only support a subset because of processing, cost and battery considerations. Therefore design of a WLAN for voice may entail compromising over-the-air security to accommodate available handsets. We believe the correct approach is as below: first choose a handset, then see if it can support the desired security model (the goal should be that voice and data work at the same level, e.g. WPA2/802.1x). If the handset cannot attain this level, the network designer should take steps to make sure that they can be allowed onto the network, but that special security measures prevent intruders from posing as voice clients to hack into the network, as explained below.
First, identify the desired handset or range of handsets. This is a general rule for adding voice services: start with the handset. Choice is often based on factors such as durability, aesthetics, PBX features supported, voice & data capabilities.
Now examine the security capabilities. While a few months ago many handsets were limited to WEP security, a new generation is now available and the network designer should aim for WPA/PSK as a minimum level of security. WPA2 is better, with WPA2/802.1x preferable to WPA2PSK, but performance, particularly handover performance will suffer as more sophisticated security is used. We favour Opportunistic Key Caching (OKC) with WPA2 for excellent security with fast handover.
Good security design requires a comprehensive approach, so it is important to examine other aspects of the network. Many networks use a separate VLAN to segregate voice traffic, although VLANs are not a good security tool and converged voice/data clients cannot be accommodated with this model.
Other approaches involve using firewall functionality to identify and police voice traffic, particularly when the voice handsets cannot offer the same level of authentication/encryption as Wi-Fi data clients. This is obviously Aruba’s approach, as we have an integrated, Wi-Fi aware firewall.
At Aruba, we have found that re-keying in an 802.1x network can stress a handset’s processor to the degree that it can interrupt voice calls. Therefore we now have a feature that delays re-keying till the handset is idle (not on a call). An alternative, but inferior approach is to use a longer re-keying interval for voice devices.
Handover performance
Handing over a voice call from AP to AP is a function of both the infrastructure and the client. While handover latency can be measured under laboratory conditions, there are many additional factors that affect real-life performance.
The target figure for interruptions in a voice call due to handover is 50-100 msec: at these levels the user will not notice the interruption. The state-of-the-art for lab tests is sub-20 msec.
Attention to AP spacing and RF planning as explained above will help to ensure that field experience is close to lab experience.
Security determines handover performance. Pre-shared keys allow much faster handover than 802.1x environments, although of course they are not as secure. There is not much inherent performance difference between WPA and WPA2 encryption levels, except that the latter requires more processing on the handset.
The ideal balance of security and performance today is when WPA2 is used with 802.1x and ‘opportunistic key caching’ in a centralised-controller WLAN.
802.11r is a new standard, intended to improve handover performance. In centralised WLAN architectures such as Aruba’s it offers only limited improvements, particularly if opportunistic key caching is used (see above). But 802.11r support should be on the checklist for the WLAN vendor.
Battery Life
Good battery life is an important usability consideration for voice-over-Wi-Fi installations. While much battery-saving technology depends on the handset, there are a variety of functions where the infrastructure can assist in extending battery life.
Determine desired battery life: this will depend on applications. For retail and hospital environments, where people pick up their phone in the morning or at the beginning of their shift, and return it to a charging cradle at the end of the day, a battery life of 12 hours may be adequate. This is quite easily achievable today.
However, a dual-mode cellular/Wi-Fi phone will be treated more like a cellphone, where users expect multiple days between charges. Performance is improving rapidly, but currently most dual-mode phones’ batteries will barely last for 24 hours with heavy business use. Handset vendors and WLAN infrastructure vendors, including Aruba, are innovating in this area.
U-APSD (Unscheduled, Asynchronous Power Save Delivery) is part of the 802.11e specification that the Wi-Fi Alliance is certifying as WMM-PS (Wireless MultiMedia Power Save). This offers considerable improvement in battery life over former protocols, and while few handsets support U-APSD today, any new Wi-Fi infrastructure must be U-APSD/WMM-PS capable.
ARP proxy. The key to extending battery life, particularly idle (not on-call) battery life is to reduce the LAN traffic the handset sees. The most significant type of traffic is ARP’s, and good WLANs now proxy to reduce this traffic to voice clients.
Traffic filtering. Some vendors offer features where extraneous traffic is not delivered to voice clients, thus saving the battery drain entailed in receiving and ack’ing such traffic. Many types of multicast fall into this category.
• Other features. Battery life is one of the few areas in voice-over-Wi-Fi where the standards (and drafts of future standards) are not sufficient for good performance. Therefore the customers should expect ‘proprietary’ extensions to standards in this area. Some of these require compatible clients, whereas others work with standard clients. At Aruba we have several of these, so please check with us and our competitors about the state of the standards and the state-of-the-art.
Wi-Fi Alliance Certifications
The Wi-Fi vendors and other interested parties take standards developed and published by the IEEE 802.11 committee, but most vendors today tend to develop to certifications of the Wi-Fi Alliance, a group of vendors formed to develop the market for 802.11 (and the originator of the term ‘Wi-Fi’, Wi-Fi logos, etc). Wi-Fi Alliance certifications are nearly all derived from subsets of the IEEE standards, and result in standardized tests to ensure inter-vendor interoperability. The notes above identify the most important certifications, but they are re-stated below (this is a subjective rather than a complete list: these are most relevant to voice-over-Wi-Fi infrastructure for Enterprise). In selecting a WLAN vendor, it is more practical to ask for a roadmap for these certifications rather than references to IEEE standards.
Security certifications relevant to voice to include WPA and WPA2, which are derived from 802.11i.
WMM (Wireless MultiMedia) defines over-the-air QoS from subsets of 802.11e.
WMM-PS (Wireless MultiMedia Power Save) includes U-APSD from 802.11e.
WMM-AC (Access Control) is not yet finished, but will include T-Spec signalling from 802.11e for Call Admissions Control.
‘Voice over Wi-Fi for Enterprise’ (name may change) will include parts of 802.11e, 802.11k, 802.11r and others in an attempt to ensure good performance and inter-vendor interoperability in Enterprise networks with multiple APs and other Enterprise requirements.
TROPOS NETWORKS NAMED WORLDWIDE MARKET LEADER FOR WI-FI MESH NETWORKS IN 2007
“We have continued to build upon our market and technology leadership to address the growing and evolving demand for reliable, wireless IP broadband infrastructures that can be used for multiple applications,” said Denise Barton, director of marketing for Tropos Networks.”
“Municipalities and other organizations use our solutions to improve the efficiencies of mobile workers and reduce operational costs. Cities most often use the networks for public safety – mobile police, fire and EMS vehicles; for fixed and mobile video surveillance; for utility automation, to reduce operational costs and improve billing accuracy. Industrial deployments are increasingly popular in harsh environments such as shipping ports and open pit mines where the network is used to improve business process efficiencies and reduce operating costs.”
“Our focus and commitment to the outdoor Wi-Fi mesh market is clear which is why Tropos continues to lead in market share and sales, technology innovation and customer deployments. In 2008, we look forward to working with our customers and partners to meet the needs of this exciting and growing market worldwide,” Barton concluded.
About Tropos Networks, Inc.
Tropos® Networks is the market leader in delivering metro-scale wireless mesh network systems. The company's systems have been selected to unwire more major league cities than all competitors combined and are installed in 30 countries. The patented Tropos MetroMesh™ architecture delivers the ultimate scalability, high capacity at low cost and great user experience demanded by service providers, municipalities and network users. Tropos Networks' unique expertise includes high-performance mesh software development, mesh RF engineering, metro-scale network planning, deployment and optimization, and navigating the municipal approval process. Tropos Networks is headquartered in Sunnyvale, California. For more information, please visit www.tropos.com, call 408-331-6800 or write to info@tropos.com.
Tropos and PWRP are registered trademarks of Tropos Networks, Inc. Tropos Networks, MetroMesh, AMCE, TMCX, SABRE, CMDP and Metro-Scale Mesh Networking Defined are trademarks of Tropos Networks, Inc. All other brand or product names are trademarks or registered trademarks of their respective holder(s).