Telecom Made Simple

Local UE does not provide an IP BS Manager

noreply@blogger.com (Unknown) — Fri, 26 Jul 2019 08:18:00 +0000

The UE does not provide an IP BS Manager. The end-to-end IP QoS bearer service towards the remote terminal is controlled from the GGSN. The scenario assumes that the GGSN supports DiffServ functions, and the backbone IP network is DiffServ enabled. In this scenario, the control of the QoS over the UMTS access network (from the UE to the GGSN) may be performed either from the terminal using the PDP context signaling or from the SGSN by subscription data.

The IP QoS for the downlink direction is controlled by the remote terminal up to the GGSN. The GGSN will apply receiver control DiffServ edge functions and can reclassify the data (remarking the DiffServ Code Point = DSCP). This may affect the QoS applied to the data over the UMTS access (the TFT may use the DSCP to identify the data to be allocated to the PDP context).

The end-to-end QoS is provided by a local mechanism in the UE, the PDP context over the UMTS access network, DiffServ through the backbone IP network, and DiffServ in the remote access network in the scenario shown in the figure below. The GGSN provides the interworking between the PDP context and the DiffServ function. However, the interworking may use information about the PDP context which is established, or be controlled from static profiles, or dynamically through other means such as proprietary of HTTP based mechanisms. The UE is expected to be responsible for the control of the PDP context, but this may instead be controlled from the SGSN by subscription.

3GPP Concept of QoS

noreply@blogger.com (Unknown) — Tue, 23 Jul 2019 19:14:00 +0000

3GPP Standard TS 23.207 provides the framework for end-to-end GPRS and UMTS. The end-to-end QoS architecture is provided in Figure below. It’s describes the interaction between the TE/MT (Terminal Equipment/Mobile Terminal) Local Bearer Service, the GPRS Bearer Service, and the External Bearer Service, and how these together provide Quality of Service for the End-to-End Service.

It’s also describes IP level mechanisms necessary in providing end-to-end Quality of Service and possible interaction between the IP level and the GPRS level, as well as the application level and the IP level. This covers different architectural aspects of the end-to-end Quality of Service concept and architecture with varying level of detail. In general, other specifications shall be referred to for further details; these other specifications enable the reader to acquire the full understanding of the end-to-end Quality of Service concept and architecture.

QoS Management Functions in the Network: to provide IP QoS end-to-end, it is necessary to manage the QoS within each domain. An IP BS (Base Station) Manager is used to control the external IP bearer service. Due to the different techniques used within the IP network, this communicates to the UMTS BS manager through the Translation function. The QoS management functions for controlling the external IP bearer services and how they relate to the UMTS bearer service QoS management functions.

QoS Conceptual Model: there are many different end-to-end scenarios that may occur from an UE connected to an UTMS network. The following examples depict how end-to-end QoS will be delivered for a number of scenarios that are considered to be significant.

The Concept of QoS by ETSI

noreply@blogger.com (Unknown) — Fri, 19 Jul 2019 13:09:00 +0000

ETSI standard TS 102 250-2 v2.2.1 (2011) covering the QoS aspects for popular services in GSM and 3G networks. The standard divided into 6 parts book that identified below:

• ETSI TS 102 250 Part 1 identifies QoS criteria for popular services in GSM and 3G networks. They are considered to be suitable for the quantitative characterization of the dominant technical QoS aspects as experienced from the customer perspective.

• ETSI TS 102 250 Part 2 defines QoS parameters and their computation for popular services in GSM and 3G networks.

• ETSI TS 102 250 Part 3 describes typical procedures used for QoS measurements over GSM, along with settings and parameters for such measurements.

• ETSI TS 102 250 Part 4 defines the minimum requirements of QoS measurement equipment for GSM and 3G

• ETSI TS 102 250 Part 5 specifies test profiles which are required to enable benchmarking of different GSM or 3G networks both within and outside national boundaries.

• ETSI TS 102 250 Part 6 describes procedures to be used for statistical calculations in the field of QoS measurement of GSM and 3G networks using probing systems.

General Consideration: ETSI identifies QoS criteria for popular services in GSM and 3G. They are considered to be suitable for the quantitative characterization of the dominant technical QoS aspects as experienced from the customer perspective. The criteria are described by their name and a short description from the customer point of view.

Phases of Service from the Customer's Point of View

Figure shows different phases (Quality of Service aspects) during service use from the customer’s point of view. The five QoS aspects are:

1.Network Availability: is the probability of a telecommunications service that can be offered to customers through a network infrastructure.

2.Network Accessibility: probability that users can register on the network to be successful so that the network can provide telecommunication services. Network can only be accessed when it is available to the user.

3.Service Accessibility: probability that the user can access the service you want to use., If the customer wants to use a service, the network operator should provide him as fast as possible access to the service

4.Service Integrity: describes QoS while using the service and contains elements such as the quality of the content being transmitted, such as sound quality, video quality, and the number of bits transmitted error in the file. Service integrity can only be calculated if the service is accessible to success.

5.Service Retainability: Service retainability describes the termination of services, in accordance with or against the will of the user. Explains how to end or terminate a service, whether or not the will of the user. Examples of service retain ability parameter are call cut-off ratio or the data cut-off ratio.

Grade of Service

noreply@blogger.com (Unknown) — Wed, 17 Jul 2019 01:04:00 +0000

ITU-T Recommendation E.771 proposes network Grade of Service (GOS) parameters for current and evolving land mobile services. These parameters are defined, and their target values specified, assuming that the network and the network components are operating in their normal mode (i.e. are fully operational). Further, the parameters and their target values assume normal (as opposed to distress or emergency) traffic.

In this Recommendation, the following traffic GOS parameters are specified for mobile circuit switched services:

•Post Selection Delay: defined as the time interval from the instant the first bit of the initial SETUP message containing all the selection digits is passed by the calling terminal to the access Signaling system until the last bit of the first message indicating ccall disposition is received by the calling terminal (ALERTING message in case of successful call).

•Answer signal delay: defined as the time interval from the instant that the called terminal passes the first bit of the CONNECT message to its access Signaling system until the last bit of the CONNECT message is received by the calling terminal.

•Call release delay: defined as the time interval from the instant the DISCONNECT message is passed by the user terminal which terminated the call to the access Signaling system, until the RELEASE message is received by the same terminal (indicating that the terminals can initiate/receive a new call).

•Probability of end-to-end blocking: defined as the probability that any call attempt will be unsuccessful due to a lack of network resources.

•Probability of unsuccessful land cellular handover: defined as the probability that a handover attempt fails because of lack of radio resources in the target cell, or because of a lack of free resources for establishing the new network connection. The failure condition is based either on a specified time interval since the handover request was first issued or on a threshold on signal strength.

User Perception of QoS vs Operational Performance in Practical

noreply@blogger.com (Unknown) — Sun, 14 Jul 2019 01:01:00 +0000

Why are any differences between the results of measurements of QoSE (QoS Experience by the user) and QoSD (QoS Delivered by the provider), whereas the measurement of QoS and network performance are not contradictory?

In practice, many factors that influence the customer's perception of the QoS service they received from the provider.

In general, the perception of the customer is to compare the quality of service that they feel with the quality they expect. Customer expectations are influenced by the rates they pay and the information that they know from the media and from books. In general, if a customer feels an expensive, then their expectations for service quality is high as well.

Provider of telecommunications equipment owned or rented, and operates with the standard of performance they called KPI (Key Performance Indicator). The better prepared KPI, and the more realistic service rates, the correlation between customer expectations for QoS performance telecommunications systeM, will increase.

To better understand the expectations of its customers, the provider must have good customer service. Customer service should be a very good understanding of operational performance measured through Key Performance Indicators, as well as understand the relationship between customer complaints with performance indicators.

The task is customer service is two-way. On the one hand, they should be able to answer customer complaints properly, according to the technical conditions of operation. On the other hand, they should be able to give direction to the company, the translation of the customer's wishes into technical performance criteria.

Providers that are less, in general, ignore the customer service. As a result, customers will be frustrated. Customers have been disappointed, because he felt the complaint was not answered correctly. Provider engineers also depressed, because it was already successfully operating the device in accordance with technical standards, but it is still considered bad by the company who read so many reports of customer disappointment.

QoSE (QoS Experienced by the User)

noreply@blogger.com (Unknown) — Wed, 10 Jul 2019 12:59:00 +0000

QoS experienced by users reflect the subjective point of view of a user in certain circumstances they experienced. Customer satisfaction is one of the driving factors for this type of QoS. In general, QoSE described in nontechnical parameters. Telecom service providers can measure the level of QoSE by conducting a survey to its customers or to seek advice and input from them. At this stage, a user combines personal experience with the expected technical quality of the service it uses. In addition to technological aspects, there are several other factors that affect the level of QoSE. Some of these factors such as starting from the signing of the contract between the user and the service provider, the service provider the ability to handle probleM faced by customers, and the overall relationship between the customer and the service provider. Thus, it can be concluded that QoSE quite difficult to measure because there are several factors "hidden" are not easy to identify.

QoSD (QoS Delivered by the Service Provider)
QoSD reflect the level of QoS that has been successfully achieved by the telecom service providers. QoSD can test the ability of a telecommunications service provider to deliver the promised QoS.

Radio Access Network - RAN

noreply@blogger.com (Unknown) — Mon, 08 Jul 2019 06:40:00 +0000

Here’s where we all look at the radio network. It is the most expensive part of the network. It will have many parts and pieces and could incorporate even more parts as the network matures. Let’s start by explaining that RAN means “Radio Access Network,” and it will have everything outside between the core and the end user. Most people just think of the radios, but the network is more than just radios and core. It is a complex system of connections that need to talk to each other and the core and the user’s equipment, the UE. The UE could be a smartphone, a laptop, a device in a meter or a video camera, or anything that can connect to the network. Don’t limit yourself to thinking it is just LTE because it could be Wi-Fi or another type of wireless format. 4G is a collection of high-speed formats and 5G will only add more formats and complexity to the network. It’s something that you need to be aware of when moving ahead. Although Wi-Fi never panned out as the carriers had hoped, it is still a major part of the network for offload.

Remember that this book is about deployments. We’re not diving too deep into the architecture. The heart of the RAN is the BTS, base transceiver station. The radio itself. The eNodeB is much more advanced than the radios of old. It could be any spectrum, but to give you an idea of what is in it I made a drawing below that is typical of today’s BTS.

Remember that there is more to the BTS than just receive or transmitter. It is also a router that connects the backhaul which could have a microwave. The BTS also has batteries to survive outages. Power backup will be in most macro, and small cells Wi-Fi usually won’t have power backup. Now that we have 5G you will also see servers at more sites to support cloud and edge computing. We need the radio heads at macro sites and antennas. Today’s macro BTS have separated the RF from the controller. It is the evolution that has made things so different. Small cells, on the other hand, are an all in one unit.

TDD and FDD Formats

noreply@blogger.com (Unknown) — Thu, 04 Jul 2019 11:39:00 +0000

There are two technologies for LTE. For LTE, they have FDD and TDD which both are viable options. Both are viable options. They are both used by carriers in the USA although FDD has been the choice in the past.

· What is FDD? FDD – Frequency Division Duplex is something that was used commonly in 3G. It’s paired spectrum with an uplink band and a downlink band in their specific spectrum. For 1G, 2G, and 3G this was common so you could have a talk and receive channel in the system. There is a guard band in between the transmit band and the receive band. FDD was very popular with GSM and CDMA. It is very difficult to take advantage of MIMO antenna technology in FDD compared to TDD.

· What is TDD? TDD – Time Division Duplex is where there is one large piece of spectrum used for uplink or downlink. Any part or percentage can be assigned to be the uplink or downlink. If you have 20MHz of bandwidth available, then you’re not locked into 10MHz up and 10MHz down like FDD. Instead, you have full control over how much goes up and comes down. The downside that some carriers had was the timing of the spectrum, and it's higher bands that have this. However, Wi-Fi spectrum is pretty much all TDD, and it works quite well for data. On the other hand, WiMAX used TDD, and it seemed to be taking off but it never fully blossomed and was cast aside for LTE. TDD makes MIMO technology easier to use because it is all in one band.

So, what can LTE do? It can do both, and it does do both. Just not the same equipment. You could have equipment do either LTE-TDD and LTE-FDD. Both are released commercially as well as part of the 3GPP standard. When you look at the deployments, it helps to know which format will be deployed. You see, FDD may need two antennas or a combiner to work on a tower. While TDD is all in the same spectrum and the same antenna is used for both transmit and receive. The way that today’s radio heads work it isn’t much of an issue anymore because they can handle the formats quite well. In 2016, you still can’t run them together in the same radio head, although the OEMs are working towards that functionality. Antennas are being designed to run both together by adding more ports and more weight to the antennas.

Note that Wi-Fi is TDD and ZigBee is TDD. Most Bluetooth is TDD. TDD appears to be the choice moving forward. Most 2G and 3G systems were FDD, and they are being phased out.

Carriers are learning that when everything becomes truly digital in IP format that it will matter less and less for the BTS, but antennas and spectrum efficiency become more important. As of 2016, most of the carriers already have implemented VoLTE into their main networks, all except maybe Sprint who was still relying on CDMA to carry the voice. The carriers know that when they convert VoLTE, it should be the last step to dismantling the 3G networks, saving them money in the long run by retiring 2G and 3G systems.

4G spectrum, soon to be part of 5G Spectrum

noreply@blogger.com (Unknown) — Mon, 01 Jul 2019 18:35:00 +0000

The spectrum is whatever they could get from the FCC in the USA. They get it from the spectrum auctions that the FCC holds. There is always a need for more although some carriers have yet to deploy all of what they have. With 3G they could use smaller swaths of bandwidth. 4G changed that, and 5G will only make them want more.

Spectrum is tough to show because there is 4G spectrum for auction here in the USA. I realize that spectrum goes to the highest bidder, (in my opinion small businesses suffer). However, the rush to get spectrum has diminished by the carriers learning to make the most of the existing spectrum. While the bands are small, they have been using something called carrier aggregation to combine spectrum bands to look like one big pipe, which is awesome. The OEMs have worked to put together 2 or more bands so that they look like one big band making the end user happy with more throughput.

In the USA, there are many bands.

•710 to 716MHz paired with 740 to 746MHz used by AT&T

•746 to 757MHz paired with 776MHz to 787MHz used by Verizon Wireless

•806 to 866MHz and 869MHz which belongs to Sprint, this is the old Nextel band.

•1710 to 1785MHz and 1805 to 1880MHz is T-Mobile AWS spectrum.

•1850 to 1990 MHz is Sprint FDD spectrum.

•2.5GHz to 2.7GHz is Sprint TDD spectrum.

•More and more, it would take some time to break them all out. So much spectrum is out there, and the carriers are grabbing what they can.

5G Network Slicing

noreply@blogger.com (Unknown) — Fri, 28 Jun 2019 10:00:00 +0000

Network slicing is 5G’s way to get you everything. You see, one network will not provide all services for everyone, so they have 5G which will encompass many networks, wireless networks, into one big network. You can’t do everything with one wireless network. Like Steven Wright says, “You can’t have everything. Where would you put it?” If you had one network, it would not be efficient enough to serve all the devices on it. You want a network that works. Otherwise, you have a notwork because it does not work! Most IOT devices don’t need broadband. Most smartphones need mobile coverage. Most laptops need broadband. Most gamers need massive broadband to get the VR to work. Each specific group has a different need. Wouldn’t it be nice if you could have several different wireless networks and have them all go into one core and share resources? Well, 5G came up with network slicing so we can do just that!

The research on network slicing showed me one thing that this is a fancy way to say different networks all connected to a common core. I think this term is interesting, but if you are in IT, then you know that you could have multiple networks, virtual or separated, all sharing the same backbone or even the same physical network. The way I see it, it is all about the RAN! Let’s explore why.

Well, in 5G, it is not much different. The big difference is that you could have a wireless network dedicated to a specific service. What this means is that when planning a network, in this case, a RAN network, make sure you know what the application will be so that you can plan accordingly.

Think about the different markets 5G will be serving. It could be autonomous cars, virtual reality, or tons of simple IOT devices. Each system will have different need and purpose. The goals are not the same for each. Therefore, they should not all share the same network. So, for the 5G network to include them all, they came up with a cool term like network slicing. The reality is that they will all be different networks that could be sharing the same core or even backhaul. We are creating a way to share resources and build in efficiencies.

We’ll get into why in a few minutes, let’s look at how they will work together first. It’s all about sharing of resources. Think of the HetNet, (Heterogeneous Network) and how we had small cells working with Macrocells and Wi-Fi all working together as one network. Now you have multiple networks all working independently, yet, connecting to the common core.

Which resources are shared in network slicing? The backhaul and the core but also routers and servers and possibly even cloud resources. The key to getting latency down is to rely on the cloud. However, the end user will determine which network will be used and how it will be utilized. The way I see it, from a wireless viewpoint is that the device will need to have a wireless network that fits the needs. In other words, virtual reality with need low latency and very high bandwidth to work properly. Autonomous cars will have very low latency but lower bandwidth needs. IOT devices will have medium latency but very low data rates, and they will not be listening to the network all the time like the other 2, they will only listen to the network on a need to know basis.

The examples above show us that there will be a need for specific wireless networks to serve each purpose. The common denominator will the core. The core will need to know how to process each part of the network. Making the major carriers happy that they have resource sharing capabilities to save costs. They want to reuse as many resources as possible. Device manufacturers will continue to improve devices and battery life.

Why Narrow Bandwidth systems in 5G?

noreply@blogger.com (Unknown) — Tue, 25 Jun 2019 06:30:00 +0000

Narrow band is for IOT devices. You see, with LTE and Wi-Fi, they tend to be on the air all the time which means the device, a smartphone or your laptop, will be listening and processing data all the time. With IOT devices, they don’t need to talk all the time. They could be pinged once a day or even just talk when they have something to say.

While there are several reasons, the main one is battery life. If it is talking all the time, then the power draw is constant and high. Broadband kills any battery because it is talking all the time. To get a 10-year battery life, you need to plan when or how it will talk and listen. You don’t want it drawing on that battery 24/7 because it’s listening and processing data. Think about your laptop and how the Wi-Fi will drain the battery life, just like the display. These are the main draws of power. Well, with many IOT devices there is no display, so they only massive power draw is the radio. If you can have the radio go to sleep until it is needed or to wake up at a time of day, then the battery will last a very long time.

For example, if you have a water sensor or a gas meter or a water meter, three devices that could be mounted where there is no available power source, you need to make sure that battery will last a very long time. Each device will have a different function.

•The water sensor may only wake up to send a beacon to let the system know that it is alive and working unless there is a high-water alarm, then it will send out alerts. This way the battery will only work when it must.

•For the metering, gas or water, it doesn’t need to send information all the time. Only maybe once a month or when it’s queried. It may send information of the usage is extremely high to let people know that there is a massive draw on the product measured. This way the battery will last a very long time, and the company deploying these devices will not need to run power to everything.

These are just a few examples of how the narrowband will be a slice of the 5G network.

Why the need for 5G Low Latency?

noreply@blogger.com (Unknown) — Sat, 22 Jun 2019 07:00:00 +0000

The key to true 5G high bandwidth needs as well as low bandwidth needs. The quick response for most devices will be needed so that applications can “talk” as close to real time as possible. You may have seen the RTC, Real Time Communication, a term tossed around RTC is where the device needs to react very quickly, and there is little time for delay. For instance, self-driving cars., They must process the data, so when they communicate with the devices around them, they need to have as little delay as possible. I am talking microseconds, not milliseconds. Why? Because they still need time to process the data.

Self-driving cars won’t just talk to the network, but they will be talking to cars around them, “looking” all around them, driving the car, making thousands of decisions every second, millions every minute. Deciding how to prepare for the road ahead, the environment around them, and what’s the next move. They will always be concerned about what’s next outside the car and inside the car.

Therefore, the communications system must talk quickly, hence, low latency.

What Applications will 5G have?

noreply@blogger.com (Unknown) — Thu, 20 Jun 2019 06:19:00 +0000

For one it will have all that you do now on 4G, internet connection, all the apps, all the things you’re doing now that you feel you can’t live without.

The new applications will push the network beyond the limitations that we know today and into virtual reality and IoT connections and more streaming video that we could not have before.

One more thing that is driving it? Vehicle to Vehicle communications. It is the thing that we expect to change the way we live. Vehicles that can communicate with each other to make the chances of accidents lower than ever, in theory anyway. It is also pushing the limits of driverless cars. We are hoping that someday in the next five years that driverless cars are commonplace. Can you imagine that? It would reduce the chance of death on the highways and roads in general. The network will be responsible for all of this, albeit more than 5G but the network reliability, latency, and speed. This falls under the Internet of Things, IOT.

In the enterprise, we will have real-time reporting of KPIs, or stock trades, or horse races that we can get real-time results on, even see the action take place in real time.

Sporting events can offer you the best seat in the house at your home, or at a bar or even at any remote location by showing the game in virtual reality. Think about that, watching the game, be it American Football, Soccer or football, baseball, rugby, cricket, or any Olympic event as if you were in the stadium. The only thing you won’t get is the smell of the arena or someone spilling beer on you. Invite me over, and I can take care of the beer spilling part.

What about smart cities? Suddenly we pushed cities into the idea that they can see all the city at any time. I know you’re thinking that big brother is watching, but what if big brother was looking at traffic patterns, accidents, traffic delays? They may be able to help or at least report it so that you know to go a different way and in real time. They would also see major potholes in the road and warn is that it is ahead.

The smart home will go to the next level. When the new networks come online, we should have improved battery life with greater efficiency so that we can take the devices out of the home, away from power, and rely on batteries for months instead of days. We could track pets, bikes, anything that we leave outside for a fraction of the cost it would take to do it now.

Health services for taking medicine and tracking health conditions will improve, we see it now, it will go to the next lever for real-time reporting anywhere and anytime.

Drones are always brought up, but the network for drones should be large. With drones, they may have a near field 5G connection that would allow them to control and upload and download data. It is the network that will enable these devices to get their information, but they will need to be autonomous at some point. The network can give them the updates and information they need for the flight path but they need to be able to talk to each other in the air, this is where a small 5G mm-wave network can come in handy.

Controlling Telecom in a Centralized Way

noreply@blogger.com (Unknown) — Tue, 18 Jun 2019 06:00:00 +0000

Telecom management is one area where centralized control tends to generate better results. Of course it isn’t an absolute truth; multinational companies must balance the benefits of centralized management against the difficulties of managing infrastructures in different countries with different languages, currencies, and cultures.

It is our experience that policies and standards should be defined globally as far as possible. This creates an environment where teamwork and cross-regional support are possible, greatly enhancing the efficiency of the human capital deployed across the organization. Here we emphasize the need to have unified inventory databases, processes, and technological standards. Sometimes, several arms of a large organization spread around the world do not understand the benefits of unified policies and standards. Usually, the telecommunications team in each country tends to believe that its own ways are the best, but anyone who has managed a multinational telecommunications area knows that having standards is better, even if they are not going to be optimal in every environment. When telecom management is centralized, it leads to the following benefits:

• better prices (usually due to global negotiation, where the full weight of the organization is brought to the table, yielding better discounts)

• better control (when only one group is responsible for telecom resources, it usually reduces problems such as overcharges, overlaps, and having unidentified resources or resources that are not used)

• lower operational costs (when headcounts are reduced, there is a consequent reduction in personnel costs)

Centralizing control usually enables the organization to identify its telecom expenses. That fact alone is usually enough to justify centralization, because it shows how much telecom represents within the IT/infrastructure budget and keeps the subject on management’s radar.

In more general terms, we have to keep in mind that telecom is a logistic system, and as such, the whole may be more than the sum of the parts.

It would be interesting to insert a caveat into the argument here that centralized management doesn’t necessarily mean a centralized operation. If you have the right tools, you may be able to control and contract in a centralized way and yet keep the operation distributed, enabling different telecom teams to operate in different countries, for example.

This is feasible, as long as you manage to make all teams use the same management tools, under a defined hierarchical framework. That means that the local telecom teams may have some autonomy to contract telecom resources (the ones not covered for the worldwide contract, for example), but they have to include each contract and resource in a corporate telecom management tool in such a way that headquarters can see all the telecom expenditures and all resources contracted in all countries. The local teams will see only their own expenditures and resources.

Therefore, we may divide the term “centralization” into two types: financial and technical. Even if operational aspects force technical decentralization, financial centralization remains crucial. The centralized telecom management has to keep track of what is contracted and how much it is costing. Financial centralization refers to the following:

• centralized resource inventory (including data, voice, and mobile resources)

• centralized contract inventory (including voice, data, mobile services, and maintenance)

• centralized telecom bills (even if received in different countries, all bills would be included in a common tool in a standardized framework, allowing centralized control)

• centralized billing system

• centralized bill auditing process (at least in a country basis) Technical centralization refers to the following:

• centralized help desk for telecom issues

• centralized point of contact with the telecom providers

• centralized point of contact for equipment maintenance

• centralized network operational center (NOC)

Benefits of Unified communications

noreply@blogger.com (Unknown) — Mon, 24 Aug 2015 14:27:00 +0000

Benefits of UC

Unified communications offers a measurable benefit for companies by value-enhancing usage to allow easy communication combined with simultaneous exchange of information among users in their daily communication.

To further explain the term unified communications (UC) at this point, the word unified means to bring everything together in real-time communication (RTC). In contrast to unified messaging (integration of telephony, fax, and voicemail), the idea behind unified communications is a merger of all available communications services, especially instant messaging systems (which are the integration with presence features) to facilitate the accessibility of communication partners.

The further integration of this technology in our work and business processes is an important focus and also an increasingly frequent request to the technology vendors and manufacturers. Unified communications can be understood as an extension of unified messaging because unified messaging refers to the integration of messages in an application and is in fact a form of asynchronous communication. Unified communications takes this a step further to create real-time communication as it aims to integrate synchronous communication media together.

Also note that the possibilities of unified communication from the portal and social networking platform technologies have also increased. You will certainly have heard of Google+, Netlog, SkyDrive, Facebook, Twitter, LinkedIn, XING, and other platforms. These platforms allow not only the exchange of personal and business-related information, but also the integration and availability of further real time communication and collaboration add-ons like instant messaging, document-sharing, Internet telephony and even integration with line of business applications.

We do not only focus on the way information within the companies is changing but also we have to keep an eye on how the consumer environment is changing.

The integration of such services has shifted from a pure consumer to a business or consumer/business mixed variant and very often, communication with business and private contacts overlap.

Let's take a look at Facebook. Facebook created at first a social networking platform to give people the opportunity to get connected, exchange content like pictures, personal information, friend lists, and more. Several years later, Facebook created a new platform inside the original Facebook application with the name Branchout. Branchout's idea was derived from Facebook. Branchout sets out to provide similar features to Facebook but for business. The idea is comparable to other social networks like Linkedin or XING where people get connected, create business, or find jobs and career opportunities. With Branchout, Facebook went into a more business related and focused area—integrated in the private social network.

Social networks offer an important platform for product information and sales. International studies have shown that in the future, more products and services through social networks and platforms can be distributed and rated, just like departmental stores or shops.

The technology allows us to communicate with "friends" and contacts about the quality of the product and to write a review providing information on the product. This is only one example of social networks. Another good example is product marketing. How companies provide information about their services and products changed completely with the development of social networks. Facebook, Twitter, LinkedIn, Amazon, Google, Microsoft, and other companies changed how customers receive information when shopping for products and services. The technology trend is clear: this change will continue. Online shops, marketing, and access to products and service information through social networks will be the standard for the new generation of end users and buyers.

Other trends include increased networking with business applications for companies. Many manufacturers and software companies also increasingly offer their solutions to integrate and coexist with social platforms. For example, Microsoft, Cisco, and IBM offer networking with Facebook and other social networks in its collaboration solutions. They are simplified to integrate communication, information, and contact databases. It will be no surprise that solutions available on the desktop and office computers will also be further extended to mobile devices such as tablets in the near future.

Reducing Security Handoff Overhead with Opportunistic Key Caching

noreply@blogger.com (Unknown) — Mon, 30 Apr 2012 10:31:00 +0000

The good news is that the 802.1X mechanisms can be taken out of the picture for handoffs, for wireless architectures with a controller (or large number of radios in one access point). This mechanism, available today for many vendors, is known as opportunistic key caching (OKC). The name comes from the main concept underlying the technology. Once a client performs the authentication with the RADIUS server, and has a PMK, there is no reason for it to have to negotiate a new one just to handoff and create a new PTK just for that access point. The term "opportunistic" is used because the mechanism was designed to be a simple extension of 802. Hi, and the client is not made aware that OKC is enabled. If it works, it works. If not, no problems arise except the increased time required for doing the handshake.

The main protocol for OKC is identical to the ordinary key caching. The only difference is that whereas ordinary key caching requires that the client is returning to an access point where it had already performed 802. IX, opportunistic key caching requires only that the new access point somehow have access to the PMK, even though it was created on a different access point.

How can this work? The PMK, if you recall, does not have any information unique to the wireless network within it. It is a function purely of the EAP protocol in use between the wireline RADIUS server and the wireless client. There is no intrinsic reason that the same PMK cannot be used for different access points, as long as the following two restrictions are held to: the PMK must never be transmitted as plaintext or using weak encryption, and the PMK must not have expired.

In practice, opportunistic key caching implementations never move around the PMK. Instead, these implementations take advantage of the architecture of the WPA2 protocol and how it interacts with 802. IX. 802. IX doesn't know about clients and access points. Instead, it uses a different language, in which the role of the user is held by a supplicant, and the role of the network is held by an authenticator. The mapping of the supplicant to real devices is clear: the supplicant is a part of the client. The authenticator, on the other hand, has flexibility built in. For standalone access point architectures, the authenticator is a part of the access point. For controller-based architectures, however, the authenticator is almost always in the controller.

Now we get a sense for the scale of opportunistic key caching. The PMK was originally created in the authenticator, and most opportunistic key caching architectures leave the PMK inside the authenticator, never to come out. For controller-based architectures, the controller generates the PTK within the authenticator, and then distributes it to the encryption engine, which may be located locally in the controller or in the access points. With opportunistic key caching, then, the only change is to allow a client with a PMK to associate to a new access point, and to use the PMK for the new connection as if it had been negotiated on that access point.

There is no addition of protocols or state changes in opportunistic key caching, which explains why it is so prevalent within network implementations. The only changes are to clients, who have to create a new PMKID, based on the original PMK, when they associate to a new access point, and to the authenticator, which needs to look past that a PMKID was not created for the PMK, create the new one, and then continue as if nothing unusual had happened.

You should look for wireless clients and network infrastructure that supports opportunistic key caching when rolling out a voice mobility network. OKC has been generally embraced by the industry, though there are a few notable exceptions, and is generally used as the solution to the 802.1X overhead.

The Wi-Fi Break-Before-Make Handoff

noreply@blogger.com (Unknown) — Thu, 26 Apr 2012 09:42:00 +0000

Basic Wi-Fi handoffs are always either break-before-make or just-in-time. In other words, there is no ability for a wireless phone to decide on a handoff and establish a relationship with a new access point without disconnecting from the previous one. The rules of 802.11 are rather simple here: no client is allowed to associate (send an Association message to one while maintaining data connectivity to another) to two access points at the same time. The reason for this is to remove any ambiguity as to which access point should forward wireline traffic destined to the client; otherwise, both access points would have the requirement of receiving the client's traffic, and therefore would not work in a switched wireline environment.

However, almost all of the important protocols for Wi-Fi happen only after a data connection has been established. This prevents clients from gaining much of a head start on establishing a connection when the old one is at risk.

Let's look at the contents of the Wi-Fi handoff protocol itself step by step. It will be helpful for further information.

Once a client has decided to hand off, it need not break the connection to the original access point, but it must not use it any longer.
The client has the option of sending a Disassociation message to the old access point, a good practice that lets the old access point free up network resources.
At this point, if the new access point is on a different channel, the client will change the channel of its receiver.
If the new channel is a DFS channel, the client is required to wait until it receives a beacon frame from the access point, unless it has recently heard one as a part of a passive scanning procedure.
The client will send an Authentication message to the new access point, establishing the beginnings of a relationship with this new access point, but not yet enabling data services.
The access point will respond with its own Authentication message, accepting the client. A rejection can occur if load balancing is enabled, and the access point decides that it is oversubscribed, or if key state tables in the access point are full.
The client will send a Reassociation Request message to the access point, requesting data services.
The access point will send a Reassociation Response message to the access point. If the message has a status code for success, the client is now associated with and connected to this access point, and only this access point. Controller-based wireless architectures will usually ensure this by immediately destroying any connection that may have been left over if step 2 has not been performed. The access point may reject the association if it is oversubscribed, or if the additional services the client requests (mostly security or quality-of-service) in the Reassociation Request will not be supported.

At this point, the client is associated and data services are available. Usually, the access point or controller behind it will send a broadcast frame, spoofed to appear as if it were sent by the client, to the connected Ethernet switch, informing it of the client's presence on that particular link and not on any one that may have been used previously.

If no security is employed, skip ahead to the admission control mechanisms, towards the end of the list. If PSK security is employed, skip ahead to the four-way handshake. Otherwise, if 802.1X and RADIUS authentication is employed (WPA/WPA2 Enterprise), we'll continue immediately next.
The access point and client can only exchange EAP messages at this point. The client may solicit the EAP exchange with an optional EAP Start message.
The access point will request the client to log in with an EAP Request Identity message.
Depending on the EAP method required by the RADIUS server on the network, the client and access point will continue to exchange a number of data frames, all EAPOL.
The access point relays the RADIUS server's EAP Success or EAP Failure message. If this is a failure, the access point will also likely send a Deauthentication or Disassociation message to the client, to kick it off of the access point.

At this point, the client and access point have agreed on the pairwise master key (PMK), based on the key material generated during the RADIUS exchange and sent to the access point when the authentication process concluded. But, the access point and client still need to generate a per-connection, pairwise transient key (PTK), which will be used to do the actual encryption. Pre-shared key (PSK) networks skipped the listed EAP exchanges, and use the PSK as the master key.
The access point send the first message in the RSN (802. Hi) four-way handshake. This is an EAPOL Key frame.
The client sends the second message in the four-way handshake.
The access point sends the third message in the four-way handshake.
The client sends the fourth message in the four-way handshake.

At this point, all data services are enabled, and the client and access point can exchange data frames. However, if a call is in progress, and WMM Admission Control is enabled, the client is required to request the voice resources before it can send or receive a single voice packet with priority. Until this point, both sides may either buffer the packets or send the voice packets as best-effort.
The client sends the access point an ADDTS Request Action frame, with a TSPEC that specifies the over-the-air resources that both the upstream and downstream part of the voice call will occupy.
The access point weighs whether it has enough resources to accept or deny the request. It sends an ADDTS Response Action frame with the results.
If the request was successful, the client and access point will be sending voice traffic and the call successfully handed off. On the other hand, if the request fails, the client will disconnect from the access point with a Disassociation message, because, although it is allowed to remain on the access point, it can't send or receive any voice traffic.

Hopefully, everything went well and the handoff completed. On the other hand, if any of the processes failed, the connection is broken. The old connection was abandoned early on—in step 8 for sure and step 2 for more charitable clients. In order to not drop the phone call, the phone will need to restart the process from the beginning with another access point—perhaps the original access point it just left, if none is available.

You will notice that the client has a lot of work to do to make the handoff successful, and there are many places where the procedure can go wrong. Even if every request were to be accepted, any loss of some of the messages can cause long timeouts, often up to a second, as each side waits to make sure that no messages are passing each other by.

If nothing at all is done to optimize this transition, the handoff mechanics can take an additional second or two, on top of the second or so taken by the scanning process before the handoff decision was made. In the worst case, the 802.1X communication can take a number of seconds.

Part of the issue is that the mechanisms are nearly the same for a handoff as they are for when the client initially connects. This lack of memory within the network within basic Wi-Fi prevents any optimizations and requires a fresh start each time.

When Scanning Happens | Inter-Access Point Handoffs

noreply@blogger.com (Unknown) — Sun, 22 Apr 2012 13:17:00 +0000

The client's handoff is only as good as its scanning table. The more the client scans, the more accurate the information it receives, and the better decision the client can make, thus ensuring a more robust call. However, scanning can cost as much in call quality as it saves, and most certainly diminishes battery life. So how do phones determine when to scan?

The most obvious way for a client to decide to scan is for it to be forced to scan. If the phone loses connection with the access point that it is currently attached to, then it will have no choice but to reach out and look for new options. Clients mainly determine that they have lost the connection with their current access point in three different ways.

The first method is to observe the beacons for loss. As mentioned earlier, beacon frames are transmitted on specific intervals, by default every 102.4ms. Because the beacons have such a strict transmission pattern, clients—even sleeping clients—know when to wake up to catch a beacon. In fact, they need to do this regularly, as a part of the power saving mechanisms built into the standard. A client can still miss a beacon, for two reasons: either the beacon frame was collided with (and, because beacon frames are sent as broadcast, there are no retransmissions), or because the client is out of the range that the beacons' data rates allow. Therefore, clients will usually observe the beacon loss rate. If the client finds itself unable to receive enough beacons according to its internal thresholds, it can declare the access point either lost or possibly suffering from heavy congestion, and thus trigger a new scan, as well as deprioritize the access point in the scanning table. The sort of loss thresholds used in real clients often are based on a combination of two or more different types of thresholds, such as triggering a scan if a certain number of beacons are lost consecutively, as well as triggering if a certain percentage is lost over time. These thresholds are likely not to directly specifiable by the user or administrator.

The second method is to observe data transmissions for loss. This can be done for received or transmitted frames. However, it is difficult for a client to adequately or accurately determine how many receive frames have been lost, given that the only evidence of a retransmission prior to a lost frame is the setting of the Retry bit in the frame's header, something that is not even required in the newer 802.1 In radios. Therefore, clients tend to monitor transmission retries. The retry process is invoked for a frame. Retransmissions are performed for both collisions and adapting to out-of-range conditions— because the transmitter does not know which problem caused the loss, both are handled by the transmitter simultaneously reducing the transmit data rate, in hopes of extending range, and increasing backoff, in hopes of avoiding further collisions for this one frame. Should a series of frames back-to-back be retransmitted until they time out, the client may decide that the root cause is for being out of range of the access point. Again, the thresholds required are not typically visible or exposed to the user or administrator.

Voice clients tend to be more proactive in the process of scanning. The two methods just described are for when the client has strong evidence that it is departing the range of the access point. However, because the scanning process itself can take as long as it does, clients may choose to initiate the scan before the client has disconnected. (This may sound like the beginnings of a make-before-break handoff scheme, but read on to Section 6.2.3, where we see that such a scheme does not, in fact, happen.) Clients may chose to start scanning proactively when the signal strength from the access point begins to dip below a predetermined threshold (the signal strength itself is usually measured directly for the beacons). Or, they may take into account increasing—but not yet disruptive—losses for data. Or, they may add into account observed information about channel conditions, such as an increasing noise floor or the encountering of a higher density of competing clients, to trigger the scan. In any event, the client is attempting to make some sort of preprogrammed expense/reward tradeoff. This tradeoff is often related to the problems of handoff, as mentioned shortly.

Scanning may also happen in the background, for no reason at all. This is less common in voice clients, where the desire to ensure battery life acts as a deterrent, but nevertheless is employed from time to time. The main reason to do this sort of background scanning is to ensure that the client's scanning table is generally not as stale, or to serve as a failsafe in case the triggered scanning behavior does not go off as expected. One of the chief problems with determining when to scan is that the client has no way of knowing whether it is moving or how fast it may be moving. A phone held in the hands of a forklift driver can rapidly go from having been standing still for many minutes to racing by at 15 miles per hour in a warehouse. This sort of scanning, not being triggered, is the least likely to lead to a change in access point selection, but may still serve its appropriate place in a network. For data clients, as a comparison, this form of background scanning, triggered for no reason, is often driven by the operating system. Windows-based systems often scan, for example, every 65 seconds, just to ensure that the operating system has a good sense of the networks that are available, in case the user should want to hop from one network to another. This sort of scanning causes a noticeable hit in performance for a short period of time on a periodic basis.

The Scanning Process | Inter-Access Point Handoffs

noreply@blogger.com (Unknown) — Thu, 19 Apr 2012 08:30:00 +0000

The scanning table's contents come from beacons and probe requests. Scanning is a process that can be requested explicitly the user—often by performing an operation that is labeled "Reconnect." "Update," or "Scan." But far more often, scanning is a process that happens in the background or when the client decides that it is needed. To understand why the client makes those choices, we will need to look at the mechanisms of scanning itself.

There are two ways that the scanning table can be updated. When a client is associated to an access point, it has the ability to gather information about other access points on that channel. Especially when the client is not in power save mode, the client will usually ask its hardware to let it receive all beacon frames from any access point. Each beacon frame is then used to update the scanning table entry for that access point.

On the other hand, the client may want to survey other channels to find out what other access point options are out there. To do this, the client clearly needs to leave the channel of its access point for at least a small amount of time. Therefore, before engaging in this process, the client will usually tell the access point that it is going into power save mode, even though it is doing no such thing. That way, the access point will buffer traffic for the client, who can then look around the network with impunity.

When the client changes channels, it has two methods it can use to find out about the access points. The quickest method is to send out the probe request mentioned earlier. This probe request contains the SSID the client desires (with the option of a null SSID, an empty string, if the client wants to learn about all SSIDs), and is picked up by all access points in range that support the SSID and wish to make themselves known to the client. Each access point that wishes to answer and that supports the SSID in question will respond with the probe response, a frame that is nearly identical to a beacon but is sent, unicast, directly to the client who asked for it. This procedure is called active scanning, though it can also be called probing, given the name of the frames that carry out the procedure. The other option is called passive scanning, and, as the name suggests, involves sending no frames out by the client. Instead, the client waits around for a beacon. Keep in mind that passive scanning clients do not know, ahead of time, how many access points are on a channel or when these access points may transmit the beacons. Therefore, a client may need to wait for at least one beacon period to maximize its chances of seeing beacons from every access point of possible interest.

In these two ways, the client goes from channel to channel, collecting as much information as possible about the available networks.

Clients may choose between active or passive scanning for a number of reasons. The advantage of active scanning is that the client will get definitive answers about the access points that are on that channel and in range in short order. Sometimes the client needs to send more than one probe request, just to make sure that none of those broadcast frames were lost because of transient RF effects or collisions. But the process itself concludes rather quickly. Furthermore, active scanning with probe requests is the only way to learn about which access points serve SSIDs that are hidden, where hidden SSIDs are not put in beacons and require the user to enter the SSID by hand. On the other hand, active scanning comes with two major penalties. The first one is for sheer network overhead. A probe request can trigger a storm of probe responses to the client, all of which take up valuable airtime. Especially when there is a network fluctuation (access point reboots, power outages, or RF interference), all of the probes pile onto an already fragile network, making traffic significantly worse. The second penalty is that active scanning is simply not allowed on the majority of the 5GHz channels. Any channel that is in a DFS band cannot be used with active scanning. Instead, the client is always required to wait for a beacon (an enabling signal), to know that the channel is allowed for operation, does not have a radar, and thus can be used. (Note that, once a client has an enabling signal, it is allowed to proceed with a probe request to discover hidden SSIDs. However, the time hit has been taken, and the process is no faster than a normal passive scan.)

Therefore, to better understand scanning, we need to look at the timing of scanning. Active scanning, of course, is the quicker process, but it too has a delay. Active scanning is limited by a probe delay, required by the standard to prevent clients from tuning into a channel in the middle of an existing transmission. The potential problem is that a client abruptly tuning into a channel might not be able to detect that a transmission is under way—carrier sense mechanisms that are based on detecting the preamble will miss out, and thus produce a false reading of a clear channel. Thus, if the client were then to send a probe request, the client could very well destroy the ongoing transmission and lose out on the access points' seeing the probe request, because of a collision. As it turns out, many voice clients set that probe delay to a trivial value, in order to not have to wait. But the common value for that delay is 12ms, which is a long time in the world of voice. Passive scanning is worse. Most access points send their beacons every 102.4ms, or as close as they can get. This means that a client who tunes to a channel has a good chance of having to wait 50ms just to get a beacon, and may have to wait the entire 100ms in the worst case, for just that one access point.

The timescale that dominates, for voice mobility, is the voice packet arrival interval. Normally, that value is 20ms (though it can be 30ms in some cases). A client will usually want to get all of the scanning it can get done in those 20ms, so that it can return to its original channel and not miss the next voice packet. Certainly, the client will not want to take 100ms unless it has to, because 100ms is a long enough jitter that it can be quite noticeable. Again, this tends to make active scanning the choice for voice clients, who are always in a hurry to learn about new access points.

If the client is going to scan between the voice packets, then the client's ability to scan will probably be limited to one channel at a time. When limited this way, the client may take up to a second, easily, to scan every possible channel. There are 11 channels in 2.4GHz, 9 non-DFS channels in 5GHz, and 11 more in the DFS bands, for a total of 31 channels to scan (or 23 channels if clients make the assumption that service is provided only on channels 1, 6, and 11 in the 2.4GHz band). Of course, scanning is also a battery-intensive process, and so a client may choose to spread out the scanning activity over time.

Furthermore, the process of changing channels is not always instantaneous. Depending on the radio chip vendor, some clients will have to wait through a multimillisecond radio settling and configuration time, reprogramming the various aspects of the radio in order to ensure proper transmission on the new channel. This adds additional padding time to the individual scanning channel transitions.

Overall, this scanning delay is a major source of handoff delays, and some methods for reducing the scanning time have been created, which we will examine shortly.

The Scanning Table

noreply@blogger.com (Unknown) — Sun, 15 Apr 2012 17:34:00 +0000

Let's look at the scanning table in a bit more detail. This table is primarily a list of access point addresses (BSSIDs), and the parameters that the access point advertises. The 802.11 standard lists at least some parameters that may be useful to hold in the client's scanning table, as in Table 1.

Table 1: Scanning table contents from 802.11
Field	Meaning
BSSID	The Ethernet address of the access point's service for this SSID
SSID	The SSID text string
BSS Type	Whether the access point is a real access point, or an ad hoc device
Beacon Period	Number of microseconds between beacons
DTIM Period	How many beacons must go by before broadcast/multicast frames are sent
Timestamp	The time the last beacon or probe response was scanned for this client
Local Time	The value of the access point's time counter
Physical Parameters	What type of radio the access point is using, and how it is configured
Channel	The channel of the access point
Capabilities	The capabilities the access point advertises in the Capabilities field
Basic Rate/MCS Set	The minimum rates (and MCS for 802.11 n) that this client must support to gain entry
Operational Rate/MCS Set	The allowed rates (and MCS for 802.11n) that this client can use once it associates
Country	The country and regional information for the radio
Security Information	The required security algorithms
Load	How loaded the access point reports itself to be
WMM Parameters	The WMM parameters that the client must use once it associates
Other Information	Depends on the standards that the client and access point supports

This table contains the fields taken from the access point's beacons and probe responses. Most of the information is necessary for the client to possess before it can associate, because this information contains parameters that the client needs to adopt upon association. By looking at this table, clients can easily see which access points have the right SSID, but will not allow the client to associate. Examples are for access points that require a higher grade of security than the client is configured for, or require a more advanced radio (such as 802.1 In) than the client supports. Most of the time, however, a properly configured network will not advertise anything that would prevent a properly configured client from entering.

In addition to all of this mostly static, configuration information that the access point reports, clients may collect other information that they may themselves find useful when deciding to which access point they should associate. This information is unique to the client, based on environmental factors. Generally, this information (not that in Table 1) is far more important in determining how a client chooses where to hand off or associate to. Table 2 contains some more frequent examples of information that different clients may choose to collect. Again, there is no standard here; clients may collect whatever information they want. Roughly, the information they collect is divided into two types: information observed about the access point, and information observed about the channel the access point is on. This split is necessary, because clients have to choose which channel to use as a part of choosing which access point to associate to. Properties like noise floor or observed over-the-air activity belong to the channel at the point in place and time that the client is in. On the other hand, some properties belong directly to the access point without regard to channel, such as the power level at which the client sees the access point's beacon frames. Furthermore, some of the per-access-point information may have been collected from previous periods when the client had been associated to that access point, and measured the quality of the connection.

Table 2: Other possible scanning table contents
Field	Meaning
Signal Strength	The power level of the beacon or probe response from the access point
Channel Noise	The measured noise floor value on the channel the access point is on
Channel Activity	How often the channel the access point is on is busy
Number of Observed Clients	How many clients are on the channel the access point is on
Beacon Loss Rate	How often beacons are missed on that channel, even though they are expected
Probe Request Loss Rate	How many times probe requests had to be sent to get a probe response
Previous Data Loss Rate	If associated earlier, how much loss was present between the access point and client
Probe Request Needed	Whether the client needed to send a probe request

The scanning table is something that the client maintains over time, as a fluid, "living" menu of options. One of the challenges the client has is in determining how old, or stale, the information may be—especially the performance information—and whether it has observed that channel or access point long enough to have some confidence in what it has seen. This is a constant struggle, and different clients (even different software versions from the same client vendor) can have widely different ways of judging how much of the table to trust and whether it needs to get new information. This is one of the sources of the variability present in Wi-Fi.

The Difference between Network Assistance and Network Control

noreply@blogger.com (Unknown) — Wed, 07 Mar 2012 05:34:00 +0000

If you have read the sections on cellular handoff, you'll know that there are broadly two different methods for phone handoffs to occur. The first method, network control, is how the network determines when the phone is to hand off and to which base station the phone is to connect. In this method, the mobile phone may participate by assisting in the handoff process, usually by providing information about the radio environment. The second method, network assistance, is where the network has the ability to provide that assistance, but the mobile phone is fundamentally the device that decides.

For transitions across basic service sets (BSSs) in Wi-Fi, the client is in control, and the network can only assist. Why is this? An early design decision in Wi-Fi was made, and the organization broke away from the comparatively long history of cellular networking. In the early days of Wi-Fi, each cell was unmanaged. An access point, compared to a client, was thought of as the dumber of the two devices. Although the access point was charged with operating the power saving features (because it is always plugged in), the client was charged with making sure the connection to the network stayed up. If anything goes wrong and a connection drops, the client is responsible for searching out for one of any number of networks the client might be configured to connect to, and the network needed to learn only about the client at that point. It makes a fair amount of sense. Cellular networks are managed by service providers, and the force of law prevents people from introducing phones or other devices that are not sanctioned and already known about by the service provider. Therefore, a cell phone could be the slave in the master/slave relationship. On the other hand, with Wi-Fi putting the power of the connection directly into the hands of the client, the network never needs to have the client be provisioned beforehand, and any device can connect. In many ways, this fact alone is why Wi-Fi holds its appeal as a networking technology: just connect and go, for guest, employee, or owner.

This initial appeal, and tremendous simplicity which comes with it, has its downsides, and quickly is meeting its limitations. Cellular phones, being managed entities, never require the user to understand the nature of the network. There are no SSIDs, no passphrases to enter. The phone knows what it is doing, because it was built and provisioned by the service provider to do only that. It simply connects, and when it doesn't, the screen shows it and users know to drive around until they find more bars. But in Wi-Fi, as long as the handset owns the process of connecting, these other complexities will always exist.

Now, you might have noticed that SSIDs and passwords have to do only with selecting the "service provider" for Wi-Fi, and once the user has that down (which is hopefully only once, so long as the user is not moving into hotspots or other networks), the real problem is with the BSSID, or the actual, distinct identities of each cell. That way of thinking has a lot to it, but misses the one point. The Wi-Fi client has no way of knowing that two access points—even with the same SSID—belongs to the same "network." In the original Wi-Fi, there is not even a concept of a "network," as the term is never used. Access points exist, and each one is absolutely independent. No two need to know about each other. As long as some Ethernet bridge or switch sits behind a group of them, clients can simply pass from one to the other, with no network coordination. This is what I mean, then, by client control. In this view of the world, there really is no such thing as a handoff. Instead, there is just a disconnection. Perhaps, maybe, the client will decide to reconnect with some access point after it disconnects from the first. Perhaps this connection will even be quick. Or perhaps it will require the user to do something to the phone first. The original standards remain silent—as would have phones, had the process not been improved a bit.

Network assistance can be added into this wild-west mixture, however. This slight shift in paradigm by the creators of the Wi-Fi and IEEE standards is to give the client more information, providing it with ways of knowing that two access points might belong to the same network, share the same backend resources, and even be able to perform some optimizations to reduce the connection overhead. This shift doesn't fundamentally change the nature of the client owning the connection, however. Instead, the client is empowered with increasingly detailed information. Each client, then, is still left to itself to determine what to do and when to do it. It is an article of faith, if you will, that how the client determines what to do is "beyond the scope of the standard," a phrase in the art meaning that client vendors want to do things their own way. The network is just a vessel—a pipe for packets.

You'll find, as you explore voice mobility deployments with Wi-Fi as a leg, that this way of thinking is as much the problem as it is a way to make things simple. Allowing the client to make the choice is putting the steering wheel of the network—or at least, a large portion of the driving task—in the hands of hundreds of different devices, each made by its own manufacturer in its own year, with its own software, and its own applications. The complexity can become overwhelming, and the more successful voice mobility networks find the right combinations of technologies to make that complexity manageable, or perhaps to make it go away entirely.

Inter-Access Point Handoffs

noreply@blogger.com (Unknown) — Sat, 03 Mar 2012 23:33:00 +0000

In a voice mobility network with Wi-Fi as a major component, we have to look at more than just the voice quality on a particular access point. The end-user of the network, the person with a phone in hand, has no idea where the access points are. He or she just walks around the building, going in and out of range of various access points in turn, oblivious to the state of the underlying wireless network. All the while, the user demands the same high degree of voice quality as if he or she had never started moving.

So now, we have to turn our focus towards the handoff aspect of Wi-Fi voice networks. Looking back on how Wi-Fi networks are made of multiple cells of overlapping coverage, we can see that the major sources for problems with voice are going to come from four sources:

How well the coverage extends through the building
How well the phone can detect when it is exiting the coverage of one access point
How well the phone can detect what other options (access points) it has available
How quickly the phone can make the transition from the old access point to the new one

Let's try to gain some more appreciation of this problem. Figure 1 shows the wireless environment that a mobile phone is likely to be dwelling within.

Figure 1: The Handoff Environment

As the caller and the mobile phone move around the environment, the phone goes into range and out of range of different access points. At any given time, the number of access points that a client can see, and potentially connect to, can be on the order of a dozen or more in environments with substantial Wi-Fi coverage. The client's task: determine whether it is far enough out of range of one access point that it should start the potentially disruptive process of looking for another access point, and then make the transition to a new access point as quickly as possible. The top part of Figure 1 shows the phone zigzagging its way through a series of cells, each one from an access point on a different channel. Looking at the same process from the point of view of the client (who knows only time), you can see how the client sees the ever-varying hills and valleys of the differing access points' coverage areas. Many are always in range; hopefully, only one is strong at a time.

The phone is a multitasker. It must juggle the processes of searching for new access points and handing off while maintaining a good voice connection. In this section, we'll go into details on the particular processes the phone must go through, and what technologies exist to make the process simpler in the face of Wi-Fi. But first, we will need to get into some general philosophy.

Active Voice Quality Monitoring

noreply@blogger.com (Unknown) — Thu, 01 Mar 2012 05:29:00 +0000

A large part of determining whether a voice mobility network is successful is in monitoring the voice quality for devices on the network. When the network has the capability to measure this for the administrator on an ongoing basis, the administrator is able to devote attention to other, more pressing matters.

Active voice quality monitoring comes in a few flavors. SIP-based schemes are capable of determining when there is a voice call. This is often used in conjunction with SIP-based admission control. With SIP calls, RTP is generally used as the bearer protocol to carry the actual voice, SIP-based call monitoring schemes can measure the loss and delay rates for the RTP traffic that makes up the call, and report back on whether there are phones with suffering quality. In these monitoring tools, call quality is measured using the standard MOS or R-value metrics.

SIP-based schemes can be found in a number of different manifestations. Wireline protocol analyzers are capable of listening in on a mirror port, entirely independent of the wireless network, and can report on upstream loss. Downstream loss, however, cannot be detected by these wireline mechanisms. Wireless networks themselves may offer built-in voice monitoring tools. These leverage the SIP-tracking functions already used for firewalling and admission control, and report on the quality both measured by uplink and downlink loss. Purely wireless monitoring tools that monitor voice quality can also be employed. Either located as software on a laptop, or integrated into overlay wireless monitoring systems, these detect the voice quality using over-the-air packet analysis. They infer the uplink and downlink loss rates of the clients, and use this to build out the expected voice quality. Depending on the particular vendor, these tools can be thrown off when presented with WPA- and WPA2-encrypted voice traffic, although that can sometimes be worked around.

Voice call quality may also be monitored by measurements reported by the client or other endpoint. RTCP, the RTP Control Protocol, may be transmitted by the endpoints. RTCP is able to encode statistics about the receiver, and these statistics can be used to infer the expected quality of the call. RTCP may or may not be available in a network, based on the SIP implementation used at the endpoints. Where available, RTCP encodes the percentage of packets lost, the cumulative number of packets lost, and interarrivai packet jitter, all of which are useful for inferring call quality. At a lower layer, 802.11k, where it is supported, provides for the notion of traffic stream metrics. These metrics also provide for loss and delay, and may also be used to determine call quality. However, 802.11k requires upgrades to the client and access point firmware, and so is not as prevalent as RTCP, and nowhere near as simple to set up as overlay or traffic-based quality measurements.

^[*]Of course, there had to be a catch. Some devices can carry two calls simultaneously, if they renegotiate their one admitted traffic stream to take the capacity of both. Because WMM Admission Control views flows as being only between clients and access points, the ultimate other endpoint of the call does not matter. However, this is not something you would expect to see in practice.

Spectrum Management | Voice Mobility with Wi-Fi

noreply@blogger.com (Unknown) — Sun, 26 Feb 2012 16:28:00 +0000

Spectrum management is the technology used by virtualization architectures to manage the available wireless resources. Unlike radio resource management, which is focused on adjusting the available wireless resources on a per-access-point basis, to ensure that the clients of that access point receive reasonable service without regard to the neighbors, spectrum management takes a view of the entire unlicensed Wi-Fi spectrum within the network, and applies principles of capacity management to the network to organize and optimize the layout of channel layers. In many ways, spectrum management is radio resource management, applied to the virtualized spectrum, rather than individual radios.

Spectrum management focuses on determining which broad swaths of unlicensed spectrum are adequate for the network or for given applications within the network. One advantage of channel layering is that channels are freed from being used to avoid interference, and thus can be used to divide the spectrum up by purposes. Much as regulatory bodies, such as the FCC, divide up the entire radio spectrum by applications, setting aside one band for radio, another for television, some for wireless communications, and so on, administrators of virtualization architectures can use spectrum management to divide up the available channels into bands that maximize the mutual capacity between applications by separating out applications with the highest likely bandwidth needs onto separate channel layers.

The constraints of spectrum management are fairly simple. A deployment has only a given number of access points. The number and position of the access points limits the number of independent channel layers that can be provided over given areas of the wireless deployment area. It is not necessary for every channel layer to extend across the entire network—in fact, channel layers are often created more in places with higher traffic density, such as libraries or conference centers. The number of channel layers in a given area is called the network thickness. Spectrum management can detect the maximum number of channel layers that can be created given the current deployment of access points, and is then able to determine when to create multiple layers by spreading channel assignments of close access points, or when to maximize signal strength and SNR by setting close access points to the same channel. Thus, spectrum management can determine the appropriate thickness for each given square foot. For 802.1 In networks, spectrum management is able to work with channel widths, as well as band and channel allocations, and is thus able to make very clear decisions about doubling capacity by arranging channels as needed.

Spectrum management also applies the neighboring-interference-avoidance aspects that RRM uses to prevent adjacent networks from being deployed in the same spectrum, if it can at all be avoided. Because there is no per-channel performance compromise in compressing the thickness of the network, spectrum management can avoid some of the troublesome aspects of radio resource management when dealing with edge effects from multiple, independent networks. Furthermore, spectrum management is not required to react to transient interference, as the channel layering mechanism is already better suited to handle transient changes through RF redundancy. This allows spectrum management to reserve network reconfigurations for periods of less network usage and potential disruption (such as night), or to make changes at a deliberate pace that ensures network convergence throughout the process.

Voice-Aware Radio Resource Management

noreply@blogger.com (Unknown) — Thu, 23 Feb 2012 14:06:00 +0000

The concept of voice-aware radio resource management is to build upon the measurements used for determining network capacity and topology, and integrate them into the decision-making process for dynamic microcell architectures.

Basic radio resource management is more concerned with establishing minimum levels of coverage while avoiding interference from neighboring access points and surrounding devices. This is more suitable for data networks. Voice-aware RRM shifts the focus towards providing a more consistent coverage that voice needs, often adjusting the nature of the RRM process to avoid destroying active voice calls. Voice-aware RRM is a crucial leg of voice mobility deployments based on microcell technology. (Layered or virtualized deployments do not use the same type of voice-aware RRM, as they have different means of ensuring high voice quality and available resources.)

The first aspect of voice-aware radio resource management is ironically to disable radio resource management. Radio resource management systems work by the access points performing scanning functions, rather similar to those performed by clients when trying to hand off. The access point halts service on a channel, and then exits the channel for a short amount of time to scan the other channels to determine the power levels, identities, and capacities of neighboring access points. These neighboring access points may be part of the same network, or may belong to other interests and other networks. Unlike with client scanning, in which the client can go into power save to inform the access point to buffer frames, however, access point scanning has no good way for clients to be told to buffer frames. Moreover, whereas client scanning can go off channel between the packets of the voice call, only to return when the next packet is ready, an access point with multiple voice calls will likely not have any available time to scan in a meaningful way. In these cases, scanning needs to be disabled. In RRM schemes without voice-aware services, administrators often have to disable RRM by hand, thus nullifying the RRM benefits for the entire network. Voice-aware RRM, however, has the capability to turn off scanning on a temporary basis for each access point, when the access point is carrying voice traffic. There are unfortunately two downsides to this. The first is that RRM is necessary for voice networks to ensure that coverage holes are filled and that the network adapts to varying density. Disabling the scanning portion of RRM disables RRM, effectively, and so voice-aware RRM scanning works best when each given access point does not carry voice traffic for uninterrupted periods of time. Second, RRM scanning is usually the same process by which the access points scan for wireless security problems, such as rogue access points and various i ntrusions. Disabling scanning in the presence of voice leaves access points with voice more vulnerable, which is unacceptable for voice mobility deployments. Here, the solution is to deploy dedicated air monitors, either as additional access points from the same network vendor, but set to monitor rather than serve, or from a dedicated WLAN security monitoring vendor, as an independent overlay solution.

The second aspect of voice-aware radio resource management is in using coverage hole detection and repair parameters that are more conservative. Although doing so increases the likelihood of co-channel interference, which can have a strong downside to voice mobility networks as the network scale and density grows, it is necessary to ensure that the radio resource management algorithms for microcells do not leave coverage holes stand by idle. Coverage holes disproportionately affect the quality of voice traffic over data traffic. Increasing the coverage hole parameters ensures that these coverage holes are reduced. Radio resource management techniques often detect the presence of a coverage hole by inferring them from the behavior of a client. RRM assumes that the client is choosing to hand off from an access point when the loss becomes too high. When this assumption is correct, the access point will infer the presence of a coverage hole by noticing when the loss rate for a client increases greatly for extended periods of time. This is used as a trigger that the client must be out of range, and informs the access point to increase its power levels. It is better for voice mobility networks for the coverage levels to be increased prior to the voice mobility deployment, and then for the coverage hole detection algorithm to be made less willing to reduce coverage levels. Unfortunately, the coverage hole detection algorithms in RRM schemes are proprietary, and there are no settings that are consistent from vendor to vendor. Consult your microcell wireless network manufacturer for details on how to make the coverage hole detection algorithm be more conservative.

The final aspect of voice-aware RRM is for when proprietary extensions are used by the voice client and are supported by the network. These extensions can provide some benefit to microcell deployments, as they allow the network to alter some of the tuning parameters that clients use to hand off. Unfortunately, the aspects of voice-aware radio resource management trade off between coverage and quality of service, and so operating these networks can become a challenge, especially as the density or proportion of network use of voice increases. Monitoring tools for voice quality are especially important in these networks