Archive | EPC RSS feed for this section

Service exposure: a critical capability in a 5G world

2 Sep

Exposure – and service exposure in particular – will be critical to the creation of the programmable networks that businesses need to communicate efficiently with Internet of Things (IoT) devices, handle edge loads and pursue the myriad of new commercial opportunities in the 5G world.

While service exposure has played a notable role in previous generations of mobile technology – by enabling roaming, for example, and facilitating payment and information services over the SMS channel – its role in 5G will be much more prominent.

The high expectations on mobile networks continue to rise, with never-ending requests for higher bandwidth, lower latency, increased predictability and control of devices to serve a variety of applications and use cases. At the same time, we can see that industries such as health care and manufacturing have started demanding more customized connectivity to meet the needs of their services. While some of these demands can be met through improved network connectivity capabilities, there are other areas where those improvements alone will not be sufficient.

For example, in recent years, content delivery networks (CDNs) have been used in situations where deployments within the operator network became a necessity to address requirements like high bandwidth. More recently, however, new use-case categories in areas such as augmented reality (AR)/virtual reality (VR), automotive and Industry 4.0 have made it clear that computing resources need to be accessible at the edge of the network. This development represents a great opportunity for operators, enterprises and application developers to introduce and capitalize on new services. The opportunity also extends to web-scale providers (Amazon, Google, Microsoft, Alibaba and so on) that have invested in large-scale and distributed cloud infrastructure deployments on a global scale, thereby becoming the mass-market provider of cloud services.

Several web-scale providers have already started providing on-premises solutions (a combination of full-stack solutions and software-only solutions) to meet the requirements of certain use cases. However, the ability to expand the availability of web-scale services toward the edge of the operator infrastructure would make it possible to tackle a multitude of other use cases as well. Such a scenario is mutually beneficial because it allows the web-scale providers to extend the reach of services that benefit from being at the edge of the network (such as the IoT and CDNs), while enabling telecom operators to become part of the value chain of the cloud computing market.

Figure 1: Collaboration with web-scale providers on telecom distributed clouds

Figure 1: Collaboration with web-scale providers on telecom distributed clouds

Figure 1 illustrates how a collaboration with web-scale providers on telecom distributed clouds could be structured. We are currently exploring a partnership to enable system integrators and developers to deploy web-scale player application platforms seamlessly on telecom distributed clouds. Distributed cloud abstraction on the web-scale player marketplace encompasses edge compute, latency and bandwidth guarantee and mobility. Interworking with IoT software development kits (SDKs) and device management provides integration with provisioning certificate handling services and assignment to distributed cloud tenant breakout points.

In the mid to long term, service exposure will be critical to the success of solutions that rely on edge computing, network slicing and distributed cloud. Without it, the growing number of functions, nodes, configurations and individual offerings that those solutions entail represents a significant risk of increased operational expenditure. The key benefit of service exposure in this respect is that it makes it possible to use application programming interfaces (APIs) to connect automation flows and artificial intelligence (AI) processes across organizational, technology, business-to-business (B2B) and other borders, thereby avoiding costly manual handling. AI and analytics-based services are particularly good candidates for exposure and external monetization.

Key enablers

The 5G system architecture specified by 3GPP has been designed to support a wide range of use cases based on key requirements such as high bandwidth/throughput, massive numbers of connected devices and ultra-low latency. For example, enhanced mobile broadband (eMBB) will provide peak data rates above 10Gbps, while massive machine-type communications (mMTC) can support more than 1 million connections per square kilometer. Ultra-reliable low-latency communications (uRLLC) guarantees less than 1ms latency.

Fulfilling these eMBB, mMTC and uRLLC requirements necessitates significant changes to both the RAN and the core network. One of the most significant changes is that the core network functions (NFs) in the 5G Core (5GC) interact with each other using a Service-based Architecture (SBA). It is this change that enables the network programmability, thereby opening up new opportunities for growth and innovation beyond simply accelerating connectivity.

Service-based Architecture

The SBA of the 5GC network makes it possible for 5GC control plane NFs to expose Service-based Interfaces (SBIs) and act as service consumers or producers. The NFs register their services in the network repository function, and services can then be discovered by other NFs. This enables a flexible deployment, where every NF allows the other authorized NFs to access the services, which provides tremendous flexibility to consume and expose services and capabilities provided by 5GC for internal or external third parties. This support of the services subscription makes it completely different to the 4G/5G Evolved Packet Core network.

Because it is service-driven, SBA enables new service types and supports a wide variety of diversified service types associated with different technical requirements. 5G provides the SBI for different NFs (for example via SBI HTTP/2 Restful APIs). The SBI can be used to address the diverse service types and highly demanding performance requirements in an efficient way. It is an enabler for short time to market and cloud-native web-scale technologies.

The 3GPP is now working on conceptualizing 5G use cases toward industry verticals. Many use cases can be created on-demand as a result of the SBA.

Distributed cloud infrastructure

The ability to deploy network slices – an important aspect of 5G – in an automated and on-demand manner requires a distributed cloud infrastructure. Further, the ability to run workloads at the edge of the network requires the distributed cloud infrastructure to be available at the edge. What this essentially means is that distributed cloud deployments within the operator network will be an inherent part of the introduction of 5G. The scale, growth rate, distribution and network depth (how far out in the network edge) of those deployments will vary depending on the telco network in question and the first use cases to be introduced.

As cloud becomes a natural asset of the operator infrastructure with which to host NFs and services (such as network slicing), the ability to allow third parties to access computing resources in this same infrastructure is an obvious next step. Contrary to the traditional cloud deployments of the web-scale players, however, computing resources within the operator network will be scarcer and much more geographically distributed. As a result, resources will need to be used much more efficiently, and mechanisms will be needed to hide the complexity of the geographical distribution of resources.

Cloud-native principles

The adoption of cloud-native implementation principles is necessary to achieve the automation, optimized resource utilization and fast, low-cost introduction of new services that are the key features of a dynamic and constrained ecosystem. Cloud-native implementation principles dictate that software must be broken down into smaller, more manageable pieces as loosely coupled stateless services and stateful backing services. This is usually achieved by using a microservice architecture, where each piece can be individually deployed, scaled and upgraded. In addition, microservices communicate through well-defined and version-controlled network-based interfaces, which simplifies integration with exposure.

Three types of service exposure

There are three main types of service exposure in a telecom environment:

  • network monitoring
  • network control and configuration
  • payload interfaces.

Examples of network monitoring service exposure include network publishing information as real-time statuses, event streams, reports, statistics, analytic insights and so on. This also includes read requests to the network.

Service exposure for network control and configuration involves requesting control services that directly interact with the network traffic or request configuration changes. Configuration can also include the upload of complete virtual network functions (VNFs) and applications.

Examples of service-exposure-enabled payload interfaces include messaging and local breakout, but it should be noted that many connectivity/payload interfaces bypass service exposure for legacy reasons. Even though IP connectivity to devices is a service that is exposed to the consumer, for example, it is currently not achieved via service exposure. The main benefit of adding service exposure would be to make it possible to interact with the data streams through local breakout for optimization functions.

Leveraging software development kits

At Ericsson, we are positioning service exposure capabilities in relation to developer workflows and practices. Developers are the ones who use APIs to create solutions, and we know they rely heavily on SDKs. There are currently advanced developer frameworks for all sorts of advanced applications including drones, AR/VR, the IoT, robotics and gaming. Beyond the intrinsic value in exposing native APIs, an SDK approach also creates additional value in terms of enabling the use of software libraries, integrated development environments (IDEs) plug-ins, third-party provider (3PP) cloud platform extensions and 3PP runtimes on edge sites, as well as cloud marketplaces to expose these capabilities.

Software libraries can be created by prepackaging higher-level services such as low-latency video streaming and reverse charging. This can be achieved, for example, by using the capabilities of network exposure functions (NEF) and service capability exposure functions (SCEF), creating ready-to-deploy functions or containers that can be distributed through open repositories, or even marketplaces, in some cases. This possibility is highly relevant for edge computing frameworks.

Support for IDE plug-ins eases the introduction of 3PP services with just a few additional clicks. Selected capabilities within 3PP cloud platform extensions can also create value by extending IoT device life-cycle management (LCM) for cellular connected devices, for example. The automated provisioning of popular 3PP edge runtimes on telco infrastructure enables 3PP runtimes on edge sites.

Finally, cloud marketplaces are an ideal place to expose all of these capabilities. The developer subscribes to certain services through their existing account, gaining the ability to activate a variety of libraries, functions and containers, along with access to plug-ins they can work with and/or the automated provisioning required for execution.

Functional architecture for service exposure

The functional architecture for service exposure is built around four customer scenarios:

  • internal consumers
  • business-to-consumers (B2C)
  • business-to-business (B2B)
  • business-to-business-to-business/consumers (B2B2X).

In the case of internal consumers, applications for monitoring, optimization and internal information sharing operate under the control and ownership of the enterprise itself. In the case of B2C, consumers directly use services via web or app support. B2C examples include call control and self-service management of preferences and subscriptions. The B2B scenario consists of partners that use services such as messaging and IoT communication to support their business. The B2B2X scenario is made up of more complex value chains such as mobile virtual network operators, web scale, gaming, automotive and telco cloud through web-scale APIs.

Figure 2: Functional architecture for service exposure

Figure 2: Functional architecture for service exposure

Figure 2 illustrates the functional architecture for service exposure. It is divided into three layers that each act as a framework for the realization. Domain-specific functionality and knowledge are applied and added to the framework as configurations, scripts, plug-ins, models and so on. For example, the access control framework delivers the building blocks for specializing the access controls for a specific area.

The abstraction and resource layer is responsible for communicating with the assets. If some assets are located outside the enterprise – at a supplier or partner facility in a federation scenario, for example – B2B functionality will also be included in this layer.

The business and service logic layer is responsible for transformation and composition – that is, when there is a need to raise the abstraction level of a service to create combined services.

The exposed service execution APIs and exposed management layer are responsible for making the service discoverable and reachable for the consumer. This is done through the API gateway, with the support of portal, SDK and API management.

Business support systems (BSS) and operations support systems (OSS) play a double role in this architecture. Firstly, they serve as resources that can expose their values – OSS can provide analytics insights, for example, and BSS can provide “charging on behalf of” functionality. At the same time, OSS are responsible for managing service exposure in all assurance, configuration, accounting, performance, security and LCM aspects, such as the discovery, ordering and charging of a service.

One of the key characteristics of the architecture presented in Figure 2 is that the service exposure framework life cycle is decoupled from the exposed services, which makes it possible to support both short- and long-tail exposed services. This is realized through the inclusion and exposure of new services through configuration, plug-ins and the possibility to extend the framework.

Another key characteristic to note is that it is possible to deploy common exposure functions both in a distributed way and individually – in combination with other microservices for efficiency reasons, for example. Typical cases are distributed cloud with edge computing and web-scale scenarios such as download/upload/streaming where the edge site and terminal are involved in the optimization.

The exposure framework is realized as a set of loosely connected components, all of which are cloud-native compliant and microservice based, running in containers. There is not a one-size-fits-all deployment – some of the components are available in several variants to fit different scenarios. For example, components in the API gateway support B2B scenarios with full charging but there are also scaled-down versions that only support reporting, intended for deployment in internal exposure scenarios.

Other key properties of the service exposure framework are:

  • scalability (configurable latency and scalable throughput) to support different deployments
  • diversified API types for payload/connectivity, including messaging APIs (request-response and/or subscribe-notify type), synchronous, asynchronous, streaming, batch, upload/download and so on
  • multiple interface bindings such as restful, streaming and legacy
  • multivendor and partner support (supplier/federation/aggregator/web-scale value chains)
  • security and access control functionality.

Deployment examples

Service exposure can be deployed in a multitude of locations, each with a different set of requirements that drive modularity and configurability needs. Figure 3 illustrates a few examples.

Figure 3: Service exposure deployment (dark pink boxes indicate deployed components)

Figure 3: Service exposure deployment (dark pink boxes indicate deployed components)

In the case of Operator B in Figure 3, service exposure is deployed to expose services in a full B2B context. BSS integration and support is required to handle all commercial aspects of the exposure and LCM of customers, contracts, orders, services and so on, along with charging and billing. Operator B also uses the deployed B2B commercial support to acquire services from a supplier.

In the case of Operator A, service exposure is deployed both at the central site and at the edge site to meet latency or payload requirements. Services are only exposed to Operator A’s own applications/VNFs, which limits the need for B2B support. However, due to the fact that Operator A hosts some applications for an external partner, both centrally and at the edge, full B2B support must be deployed for the externally owned apps.

The aggregator in Figure 3 deploys the service exposure required to create services put together by more than one supplier. Unified Delivery Network and web-scale integration both fall into this category. As exposure to the consumer is done through the aggregator, this also serves as a B2B interface to handle specific requirements. Examples of this include the advertising and discovery of services via the portals of web-scale providers.

A subset of B2B support is also deployed to provide the service exposure that handles the federation relationship between Operator A and Operator B, in which both parties are on the same level in the ecosystem value chain.

Conclusion

There are several compelling reasons for telecom operators to extend and modernize their service exposure solutions as part of the rollout of 5G. One of the key ones is the desire to meet the rapidly developing requirements of use cases in areas such as the Internet of Things, AR/VR, Industry 4.0 and the automotive sector, which will depend on operators’ ability to provide computing resources across the whole telco domain, all the way to the edge of the mobile network. Service exposure is a key component of the solution to enable these use cases.

Recent advances in the service exposure area have resulted from the architectural changes introduced in the move toward 5G and the adoption of cloud-native principles, as well as the combination of Service-based Architecture, microservices and container technologies. As operators begin to use 5G technology to automate their networks and support systems, service exposure provides them with the additional benefit of being able to use automation in combination with AI to attract partners that are exploring new, 5G-enabled business models. Web-scale providers are also showing interest in understanding how they can offer their customers an easy extension toward the network edge.

Modernized service exposure solutions are designed to enable the communication and control of devices, providing access to processes, data, networks and OSS/BSS assets in a secure, predictable and reliable manner. They can do this both internally within an operator organization and externally to a third party, according to the terms of a Service Level Agreement and/or a model for financial settlement.

Service exposure is an exciting and rapidly evolving area and Ericsson is playing an active role in its ongoing development. As a complement to our standardization efforts within the 3GPP and Industry 4.0 forums, we are also engaged in open-source communities such as ONAP (the Open Network Automation Platform). This work is important because we know that modernized service exposure solutions will be at heart of efficient, innovative and successful operator networks.

Source: https://www.ericsson.com/en/ericsson-technology-review/archive/2019/service-exposure-a-critical-capability-in-a-5g-world

Advertisements

Why the industry accelerated the 5G standard, and what it means

17 Mar

The industry has agreed, through 3GPP, to complete the non-standalone (NSA) implementation of 5G New Radio (NR) by December 2017, paving the way for large-scale trials and deployments based on the specification starting in 2019 instead of 2020.

Vodafone proposed the idea of accelerating development of the 5G standard last year, and while stakeholders debated various proposals for months, things really started to roll just before Mobile World Congress 2017. That’s when a group of 22 companies came out in favor of accelerating the 5G standards process.

By the time the 3GPP RAN Plenary met in Dubrovnik, Croatia, last week, the number of supporters grew to more than 40, including Verizon, which had been a longtime opponent of the acceleration idea. They decided to accelerate the standard.

At one time over the course of the past several months, as many as 12 different options were on the table, but many operators and vendors were interested in a proposal known as Option 3.

According to Signals Research Group, the reasoning went something like this: If vendors knew the Layer 1 and Layer 2 implementation, then they could turn the FGPA-based solutions into silicon and start designing commercially deployable solutions. Although operators eventually will deploy a new 5G core network, there’s no need to wait for a standalone (SA) version—they could continue to use their existing LTE EPC and meet their deployment goals.

“Even though a lot of work went into getting to this point, now the real work begins. 5G has officially moved from a study item to a work item in 3GPP.”

Meanwhile, a fundamental feature has emerged in wireless networks over the last decade, and we’re hearing a lot more about it lately: The ability to do spectrum aggregation. Qualcomm, which was one of the ring leaders of the accelerated 5G standard plan, also happens to have a lot of engineering expertise in carrier aggregation.

“We’ve been working on these fundamental building blocks for a long time,” said Lorenzo Casaccia, VP of technical standards at Qualcomm Technologies.

Casaccia said it’s possible to aggregate LTE with itself or with Wi-Fi, and the same core principle can be extended to LTE and 5G. The benefit, he said, is that you can essentially introduce 5G more casually and rely on the LTE anchor for certain functions.

In fact, carrier aggregation, or CA, has been emerging over the last decade. Dual-carrier HSPA+ was available, but CA really became popularized with LTE-Advanced. U.S. carriers like T-Mobile US boast about offering CA since 2014 and Sprint frequently talks about the ability to do three-channel CA. One can argue that aggregation is one of the fundamental building blocks enabling the 5G standard to be accelerated.

Of course, even though a lot of work went into getting to this point, now the real work begins. 5G has officially moved from a study item to a work item in 3GPP.

Over the course of this year, engineers will be hard at work as the actual writing of the specifications needs to happen in order to meet the new December 2017 deadline.

AT&T, for one, is already jumping the gun, so to speak, preparing for the launch of standards-based mobile 5G as soon as late 2018. That’s a pretty remarkable turn of events given rival Verizon’s constant chatter about being first with 5G in the U.S.

Verizon is doing pre-commercial fixed broadband trials now and plans to launch commercially in 2018 at last check. Maybe that will change, maybe not.

Historically, there’s been a lot of worry over whether other parts of the world will get to 5G before the U.S. Operators in Asia in particular are often proclaiming their 5G-related accomplishments and aspirations, especially as it relates to the Olympics. But exactly how vast and deep those services turn out to be is still to be seen.

Further, there’s always a concern about fragmentation. Some might remember years ago, before LTE sort of settled the score, when the biggest challenge in wireless tech was keeping track of the various versions: UMTS/WCDMA, HSPA and HSPA+, cdma2000, 1xEV-DO, 1xEV-DO Revision A, 1xEV-DO Revision B and so on. It’s a bit of a relief to no longer be talking about those technologies. And most likely, those working on 5G remember the problems in roaming and interoperability that stemmed from these fragmented network standards.

But the short answer to why the industry is in such a hurry to get to 5G is easy: Because it can.

Like Qualcomm’s tag line says: Why wait? The U.S. is right to get on board the train. With any luck, there will actually be 5G standards that marketing teams can legitimately cite to back up claims about this or that being 5G. We can hope.

Source: http://www.fiercewireless.com/tech/editor-s-corner-why-hurry-to-accelerate-5g

The CORD Project: Unforeseen Efficiencies – A Truly Unified Access Architecture

8 Sep

The CORD Project, according to ON.Lab, is a vision, an architecture and a reference implementation.  It’s also “a concept car” according to Tom Anschutz, distinguished member of tech staff at AT&T.  What you see today is only the beginning of a fundamental evolution of the legacy telecommunication central office (CO).

The Central Office Re-architected as a Datacenter (CORD) initiative is the most significant innovation in the access network since the introduction of ADSL in the 1990’s.  At the recent inaugural CORD Summit, hosted by Google in Sunnyvale, thought leaders at Google, AT&T, and China Unicom stressed the magnitude of the opportunity CORD provides. CO’s aren’t going away.  They are strategically located in nearly every city’s center and “are critical assets for future services,” according to Alan Blackburn, vice president, architecture and planning at AT&T, who spoke at the event.

Service providers often deal with numerous disparate and proprietary solutions. This includes one architecture/infrastructure for each service multiplied by two vendors. The end result is a dozen unique, redundant and closed management and operational systems. CORD is able to solve this primary operational challenge, making it a powerful solution that could lead to an operational expenditures (OPEX) reduction approaching 75 percent from today’s levels.

Economics of the data center

Today, central offices are comprised of multiple disparate architectures, each purpose built, proprietary and inflexible.  At a high level there are separate fixed and mobile architectures.  Within the fixed area there are separate architectures for each access topology (e.g., xDSL, GPON, Ethernet, XGS-PON etc.) and for wireless there’s legacy 2G/3G and 4G/LTE.

Each of these infrastructures is separate and proprietary, from the CPE devices to the big CO rack-mounted chassis to the OSS/BSS backend management systems.    Each of these requires a specialized, trained workforce and unique methods and procedures (M&Ps).  This all leads to tremendous redundant and wasteful operational expenses and makes it nearly impossible to add new services without deploying yet another infrastructure.

The CORD Project promises the “Economics of the Data Center” with the “Agility of the Cloud.”  To achieve this, a primary component of CORD is the Leaf-Spine switch fabric.  (See Figure 1)

The Leaf-Spine Architecture

Connected to the leaf switches are racks of “white box” servers.  What’s unique and innovative in CORD are the I/O shelves.  Instead of the traditional data center with two redundant WAN ports connecting it to the rest of the world, in CORD there are two “sides” of I/O.  One, shown on the right in Figure 2, is the Metro Transport (I/O Metro), connecting each Central Office to the larger regional or large city CO.  On the left in the figure is the access network (I/O Access).

To address the access networks of large carriers, CORD has three use cases:

  • R-CORD, or residential CORD, defines the architecture for residential broadband.
  • M-CORD, or mobile CORD, defines the architecture of the RAN and EPC of LTE/5G networks.
  • E-CORD, or Enterprise CORD, defines the architecture of Enterprise services such as E-Line and other Ethernet business services.

There’s also an A-CORD, for Analytics that addresses all three use cases and provides a common analytics framework for a variety of network management and marketing purposes.

Achieving Unified Services

The CORD Project is a vision of the future central office and one can make the leap that a single CORD deployment (racks and bays) could support residential broadband, enterprise services and mobile services.   This is the vision.   Currently regulatory barriers and the global organizational structure of service providers may hinder this unification, yet the goal is worth considering.  One of the keys to each CORD use case, as well as the unified use case, is that of “disaggregation.”  Disaggregation takes monolithic chassis-based systems and distributes the functionality throughout the CORD architecture.

Let’s look at R-CORD and the disaggregation of an OLT (Optical Line Terminal), which is a large chassis system installed in CO’s to deploy G-PON.  G-PON (Passive Optical Network) is widely deployed for residential broadband and triple play services.  It delivers 2 .5 Gbps Downstream, 1.5 Gbps Upstream shared among 32 or 64 homes.  This disaggregated OLT is a key component of R-CORD.  The disaggregation of other systems is analogous.

To simplify, an OLT is a chassis that has the power supplies, fans and a backplane.  The latter is the interconnect technology to send bits and bytes from one card or “blade” to another.   The OLT includes two management blades (for 1+1 redundancy), two or more “uplink” blades (Metro I/O) and the rest of the slots filled up with “line cards” (Access I/O).   In GPON the line cards have multiple GPON Access ports each supporting 32 or 64 homes.  Thus, a single OLT with 1:32 splits can support upwards of 10,000 homes depending on port density (number of ports per blade times the number of blades times 32 homes per port).

Disaggregation maps the physical OLT to the CORD platform.  The backplane is replaced by the leaf-spine switch fabric. This fabric “interconnects” the disaggregated blades.  The management functions move to ONOS and XOS in the CORD model.   The new Metro I/O and Access I/O blades become an integral part of the innovated CORD architecture as they become the I/O shelves of the CORD platform.

This Access I/O blade is also referred to as the GPON OLT MAC and can support 1,536 homes with a 1:32 split (48 ports times 32 homes/port).   In addition to the 48 ports of access I/O they support 6 or more 40 Gbps Ethernet ports for connections to the leaf switches.

This is only the beginning and by itself has a strong value proposition for CORD within the service providers.  For example, if you have 1,540 homes “all” you have to do is install a 1 U (Rack Unit) shelf.  No longer do you have to install another large chassis traditional OLT that supports 10,000 homes.

The New Access I/O Shelf

The access network is by definition a local network and localities vary greatly across regions and in many cases on a neighborhood-by-neighborhood basis.  Thus, it’s common for an access network or broadband network operator to have multiple access network architectures.  Most ILECs leveraged their telephone era twisted pair copper cables that connected practically every building in their operating area to offer some form of DSL service.  Located nearby (maybe) in the CO from the OLT are the racks and bays of DSLAMs/Access Concentrators and FTTx chassis (Fiber to the: curb, pedestal, building, remote, etc).  Keep in mind that each of the DSL equipment has its unique management systems, spares, Method & Procedures (M&P) et al.

With the CORD architecture to support DSL-based services, one only has to develop a new I/O shelf.  The rest of the system is the same.  Now, both your GPON infrastructure and DSL/FTTx infrastructures “look” like a single system from a management perspective.   You can offer the same service bundles (with obvious limits) to your entire footprint.  After the packets from the home leave the I/O shelf they are “packets” and can leverage the unified  VNF’s and backend infrastructures.

At the inaugural CORD SUMMIT, (July 29, 2016, in Sunnyvale, CA) the R-CORD working group added G.Fast, EPON, XG & XGS PON and DOCSIS.  (NG PON 2 is supported with Optical inside plant).  Each of these access technologies represents an Access I/O shelf in the CORD architecture.  The rest of the system is the same!

Since CORD is a “concept car,” one can envision even finer granularity.  Driven by Moore’s Law and focused R&D investments, it’s plausible that each of the 48 ports on the I/O shelf could be defined simply by downloading software and connecting the specific Small Form-factor pluggable (SFP) optical transceiver.  This is big.  If an SP wanted to upgrade a port servicing 32 homes from GPON to XGS PON (10 Gbps symmetrical) they could literally download new software and change the SFP and go.  Ideally as well, they could ship a consumer self-installable CPE device and upgrade their services in minutes.  Without a truck roll!

Think of the alternative:  Qualify the XGS-PON OLTs and CPE, Lab Test, Field Test, create new M&P’s and train the workforce and engineer the backend integration which could include yet another isolated management system.   With CORD, you qualify the software/SFP and CPE, the rest of your infrastructure and operations are the same!

This port-by-port granularity also benefits smaller CO’s and smaller SPs.    In large metropolitan CO’s a shelf-by-shelf partitioning (One shelf for GPON, One shelf of xDSL, etc) may be acceptable.  However, for these smaller CO’s and smaller service providers this port-by-port granularity will reduce both CAPEX and OPEX by enabling them to grow capacity to better match growing demand.

CORD can truly change the economics of the central office.  Here, we looked at one aspect of the architecture namely the Access I/O shelf.   With the simplification of both deployment and ongoing operations combined with the rest of the CORD architecture the 75 percent reduction in OPEX is a viable goal for service providers of all sizes.

Source: https://www.linux.com/blog/cord-project-unforeseen-efficiencies-truly-unified-access-architecture

LTE Fundamentals Channels Architecture and Call Flow

7 Jan
LTE Overview
LTE/EPC Network Architecture
LTE/EPC Network Elements
LTE/EPC Mobility & Session Management
LTE/EPC Procedure
LTE/EPS overview
Air Interface Protocols

LTE Radio Channels
Transport Channels and Procedure
LTE Physical Channels and Procedure
LTE Radio Resource Management
MIMO for LTE

 

 

Source: http://www.scribd.com/doc/294799476/LTE-Fundamentals-Channels-Architecture-and-Call-Flow#scribd

LTE EPC: Addressing the Mobile Broadband Tidal Wave

24 Feb

The mobile Internet has changed the way people communicate, stay informed, and are entertained. With more compelling services and mobile multimedia computing devices, users are increasingly entering the network and creating an enormous surge in mobile traffic.

To address this new normal, operators must deploy a core network that combines performance with intelligence to meet different traffic demands with an elastic architecture. An intelligent core network allows them to create a robust multimedia environment, enhance and manage the subscriber experience, and monetize network traffic.

Long-Term Evolution (LTE) is the next-generation mobile wireless technology designed to deliver ultrahigh-speed mobile broadband. The primary goals of LTE are increasing bandwidth, improving spectral efficiency, reducing latency, lowering the cost per byte, and enabling improved mobility. This combination aims to enhance a subscriber’s interaction with the network and further accelerate the adoption of mobile multimedia services, such as online television, streaming video, video on demand (VoD), social networking, and interactive gaming.

Radio access solutions are a primary consideration of the LTE deployment strategy, because LTE affects the mobile operators’ most valued asset: spectrum. However, equally important is the multimedia core network.

The Evolved Packet Core: The Next-Generation Packet Core for All Networks

LTE calls for a transition to a “flat”, all-IP core network with open interfaces, called the Evolved Packet Core (EPC). The goal of the EPC is higher throughput, lower latency, simplified mobility between Third-Generation Partnership Project (3GPP) and non-3GPP networks, enhanced service control and provisioning, and efficient use of network resources. Although the EPC has been defined in conjunction with LTE, it is an open next-generation packet core for all networks, including 2.5G, 3G, 4G, non-3GPP, and even fixed networks. In addition, although the EPC represents one of the smallest percentages of overall wireless infrastructure spending, it provides the greatest potential effect on overall network profitability through enablement of new services combined with cost savings from operational efficiencies.

As a result, mobile operators are looking for the best multimedia core solutions to deliver an optimum user experience and migrate to an efficient, intelligent EPC.

Important considerations for the multimedia core network include:

• Support for multiple access network types, including 2.5G, 3G, and 4G; deployment flexibility and network optimization including backhaul

• Smooth and flexible evolution from 2.5G and 3G to 4G

• Massive increase in signaling

• Increased user-plane performance

• Session-state and subscriber management

• Integration of intelligence and policy control at the mobility anchor point

• Security

• Voice-grade reliability

• Reporting, monitoring, accounting, and charging

• Roaming

• Support for multimedia services over the packet switched infrastructure

Cisco is exceptionally well positioned to address these challenges and assist in the migration to an LTE EPC, bringing the products and expertise needed for this evolution.

Cisco ASR 5000 Series Platform

The Cisco ® ASR 5000 Series extended by the Cisco ASR 5500 is elastic; it combines high capacity, high availability, and powerful performance with unparalleled subscriber and network intelligence. Designed for the evolution from 3G to 4G, the Cisco ASR 5000 Series platform is the benchmark for today’s and tomorrow’s multimedia-enabled core network. The platform uses a simple, flexible distributed architecture that supports multiple access technologies, subscriber mobility management, and call-control capabilities, as well as inline services (Figure 1). With its leading-edge throughput, signaling, and capacity, the Cisco ASR 5000 Series can readily support all EPC network functions.

Figure 1. The Cisco ASR 5000 Series in a Multiaccess Multiservice Environment

EPC Network Functions

The LTE EPC performs a series of network functions that flatten the architecture by minimizing the number of nodes in the network. As a result capital and operational expenditures decrease, thereby trimming the overall cost per megabyte of traffic while improving network performance. Cisco provides the functions defined for the LTE EPC, including the following:

• The Mobility Management Entity (MME) resides in the control plane and manages states (attach, detach, idle, and Radio Access Network [RAN] mobility), authentication, paging, mobility with 3GPP 2.5G and 3G nodes (Serving GPRS Support Node [SGSN]), roaming, and other bearer management functions.

• The Serving Gateway (SGW) sits in the user plane, where it forwards and routes packets to and from the eNodeB and Packet Data Network Gateway (PGW). It also serves as the local mobility anchor for inter-eNodeB handover and roaming between 3GPP systems, including 2.5G and 3G networks.

• The Packet Data Network Gateway (PGW) acts as the interface between the LTE network and packet data networks, such as the Internet or IP Multimedia Subsystem (IMS) networks. It is the mobility anchor point for intra-3GPP and non-3GPP access systems. It also acts as the Policy and Charging Enforcement Function (PCEF) that manages quality of service (QoS), online and offline flow-based charging data generation, deep packet inspection, and lawful intercept.

• The Evolved Packet Data Gateway (ePDG) is the element responsible for interworking between the EPC and untrusted non-3GPP networks, such as a wireless LAN.

• Release 8 Serving GPRS Support Node (SGSN), also known as the S4 SGSN, provides control, mobility, and user-plane support between the existing 2.5G and 3G core and the EPC. It provides the S4 interface that is equivalent to the Gn interface used between the SGSN and the Gateway GPRS Support Node (GGSN).

The Cisco Difference

Cisco multimedia core platforms are built to address the needs of the mobile multimedia core market.

Cisco brings a history of innovative solutions that already meet many of the requirements of the EPC, such as integrated intelligence, simplified network architecture, high-bandwidth performance capabilities, and enhanced mobility.

Therefore, Cisco solutions can support 2.5G and 3G today and, through in-service software upgrades (ISSUs), will support mobile broadband functions as LTE networks are deployed. These platforms can support multiple functions in a single node, allowing a single platform to concurrently act as an MME, Release 8 SGSN and SGW, SGW and PGW, or even as a 2.5G and 3G and LTE EPC node. Mobile operators who want a smooth network migration can maximize the return on their investments and offer an exceptional experience to their customers.

Specific key features include:

Network Flexibility:

• Common platform for all network functions

• Integration and colocation of multiple core functions

• Software architecture that enables service reconfiguration and online upgrades

• Evolution from 3G to LTE

• Single operations, administration, and management (OA&M), policy, and charging integration

Superior Overall Performance:

• High performance across all parameters – signaling, throughput, density, and latency

• Linear scaling of network functions and services

• Support for 2.5G and 3G LTE service on any card running anywhere in the system

• Resources distributed across the entire system

Integrated Intelligence with Policy Enforcement:

• Integrated deep packet inspection, service control, and steering

• Value-added inline services

• Integrated policy enforcement with tightly coupled policy and charging

• Support for integrated Session Initiation Protocol (SIP) and IMS functions

• Consolidated accounting and billing

Outstanding Reliability

• No sessions lost because of any single hardware or software failure

• Automatic recovery of fully established subscriber sessions

• Interchassis session recovery or geographic redundancy

• Network Equipment Building Standards (NEBS) Level 3 certification

Conclusion

Although the deployment of LTE RANs receives considerable attention, the EPC has emerged as critical for delivering next-generation mobile broadband services. As such, mobile operators must look for solutions that can address today’s requirements while positioning them for future technologies.

Cisco is focused on the elastic multimedia core network and the challenges it presents to the mobile operator. We have led the industry with intelligent, high-performance solutions that have changed the packet core environment to a true multimedia core network. We will continue to harness this proven experience and expertise to become your trusted advisor and deliver best-in-class solutions that evolve the mobile operator’s network and help deliver on the promise of true mobile broadband.

PDF (232.9 KB)
For more information, please visit http://www.cisco.com/go/mobile.
Source: http://www.cisco.com/c/en/us/solutions/collateral/service-provider/lte-epc/whitepaper_c78-665050.html

LTE EPS Architecture Overview

30 Dec

Excellent video describing the Evolved Packet Core used in LTE networks. The video describes the roles played by the major LTE components:

  • eNodeB
  • MME
  • S-GW
  • P-GW
  • HSS

CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 3

16 Sep

Windancer - Stairway to ...Heaven?

Ref:

CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 1

CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 2

by Alex

it was about time to display a nice message flow diagram of the messages being exchanged for Combined EPS/IMSI Attach

Enjoy!

combined

View original post

CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 2

9 Sep

continuing the CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 1

I was thinking the other day and I realized that CSFB is meant to be used only if VoLTE cannot be used for some reason. That sounded strange to me as in order to be able to use CSCF you need the special combined EPS/IMSI attach but in some cases you may find yourself unable to use VoLTE after you attach. On example of such case is when the network prefers VoLTE and the UE is able to do VoLTE but IMS voice is not available (for example the registration to the IMS network fails).  To find the answer to my questions I turned to TS 23.221, maybe it can help in some way.

What I found is than an UE can be either voice centric or data centric. This usage setting basically tells the network what’s more important for that UE (voice or data). For example a voice centric UE will disconnect from E-UTRAN and try GERAN/UTRAN if it is not able to obtain voice service in E-UTRAN while a data centric UE will not do that.

Now, there’s another setting on the UE which is called voice domain preference and has one of four values CS Voice only, IMS PS Voice only, CS voice preferred, IMS PS Voice as secondary, IMS PS voice preferred, CS Voice as secondary.  Based on these 2 settings and what happens in the network the UE will prefer one of the following 4 states:

 

Voice centric UE

Data centric UE

CS Voice preferred/ CS Voice only

CS/PS mode 1

CS/PS mode 2

IMS PS Voice preferred/ IMS PS Voice only

PS mode 1

PS mode 2

* an IMS PS Voice preferred UE may still be connected to both systems.

* an IMS PS Voice Only UE will not use combined attach or CSFB

*TS 23.221 Annex A gives guidance on how a CS and IMS capable UE should behave.

On the other hand, the network has its settings and preferences too. When an UE attempts to do a combined attach, the network may inform the UE of its settings, like CS Fallback not preferred, SMS-only (the CS network is to be used to SMS over SGs only, not for CSFB) or IMS voice not available. The UE may transition between these states if its settings or the network’s settings change. Also an UE in a PS mode state will transition to the corresponding CS/PS mode state if IMS is unavailable for some reason.

Now, in order to do CSFB or SMS over SGs one needs to be in one of the CS/PS modes. To be in one of these modes the UE needs to do a combined EPS/IMSI attach. Now let’s say our UE is set to prefer the IMS for voice calls but its registration to the IMS network fails for some reason or the network indicates to the UE it does not support PS voice. In this case the UE is already connected to the EPS network but most likely not to the CS network and in order to use CSFB it needs to transition to a combined EPS/IMSI attach situation. To do this the UE will do a Combined TA/LA Update Procedure (TS 23.272 section 5.4.1).

Later edit:

Relevant specs for the UICC side:

TS 24.008 – Layer 3 specifications, Core network protocols

TS 31.102 – USIM Applications

Why? : Because I would like to see in more detail how this entire CSFB/SRVCC story happens at the UE+UICC(SIM) level.

Source: http://windancersth.wordpress.com/2013/09/07/csfb-vs-srvcc-or-how-to-sudo-make-me-voice-over-lte-take-2/

Diameter Routing Segmentation Opens the Door to a More Efficient LTE/EPC/Diameter Network

9 Sep

Can Diameter Signaling Controller capabilities overcome architectural issues within the LTE/EPC/Diameter network, thus allowing service providers the ability to build a topology that best meets their needs? In our previous posts we have discussed different types of EPC network architectures from mesh to centralized to core/edge. I think, based on all the discussion throughout the industry, we have come to the conclusion that mesh networks are not acceptable. So, the question remains, are there advantages and disadvantages to both the centralized and core/edge approaches, and furthermore, can capabilities in Diameter overcome the disadvantages?

Centralized Diameter Routing Challenges

The LTE/EPC/Diameter central routing topology is characterized by all nodes within a carrier’s network being connected to the central diameter router. Additionally, all external network connections would also terminate at the central Diameter router. This combination of a complex LTE/EPC network, numerous interconnected networks, and vendors’ wide diversity of equipment, presents service providers with the challenge of setting up routing rules, shaping traffic, and handling Diameter protocol inconsistencies on an interconnected network basis. This massive routing configuration leads to complexity and increases the chance of errors when making routing/traffic rules changes.

Centralized Diameter Routing Topology

Centralized Diameter Routing Topology


Centralized Diameter Routing Solutions

An efficient approach to the dilemma of massive routing databases and traffic shaping to individual areas of the network is for Diameter Routing Agents to include routing segmentation concepts. This routing segmentation would be used to virtulize instances of the Diameter Routing Agent on a single platform and would include individual routing and traffic shaping tables on a per Diameter Routing Agent instance. This concept would be used to subdivide the network into regions, territories, or any other category that meets the business and architectural requirements of the service provider. Furthermore, routing segmentation has the following benefits:

  • Routing table on a per region basis
  • Traffic shaping on a per region basis
  • Protocol inconsistencies on a per region or per network element basis
  • Reduction of administration errors (changes are made on a per instance basis)
  • Maintains capital expenditures savings of centralized routing

routing-segmentation-diagram2

Centralized LTE/EPC/Diameter Network with Routing Segmentation


Core/Edge Diameter Routing Challenges

In a LTE/EPC/Diameter Core/Edge network topology the issues of the core Diameter Routing Agent are similar to those in the centralized Diameter routing architecture, albeit reduced somewhat due to the more distributed nature of the network. Typically, the edge portion of the core/edge topology is the GSM Association (GSMA) recommended Diameter Edge Agent (DEA). This Diameter Edge Agent would be used to interface all interconnected networks.  The questions to be answered regarding the Centralized DEA are:

  • Can changes be made on an individual interconnected network basis?
  • Do changes made on interconnected networks have to be made in the master routing database?


Core/Edge Diameter Routing Solutions

The use of Diameter routing segmentation within Diameter Edge Agents makes it possible to virtualize the DEAs on an interconnected basis while maintaining a single platform. Diameter routing segmentation will provide the capability to solve the following in the most efficient manner:

  • Changing routing rules on a per interconnected network
  • Traffic shaping per interconnected network
  • Topology hiding per interconnected network
  • Protocol inconsistencies per interconnected network
  • Firewalling of incoming Diameter messages per interconnected network.
Diameter Edge with Routing Segmentation
Diameter Edge with Routing Segmentation

Conclusion

Diameter Routing Agents including routing segmentation capabilities give LTE/EPC/Diameter service providers the ability to design, implement, and maintain the most efficient and cost effective architectures to meet their individual business requirements.

Source: http://blog.pt.com/diameter-routing-segmentation-opens-the-door-to-a-more-efficient-lteepcdiameter-network?utm_source=linkedin&utm_medium=social&utm_content=1377623#!

Signaling Transfer Point (STP) Replacement

8 Aug

As telecommunications service providers worldwide navigate the uncharted waters of network migration from either circuit switched to VoIP/IMS or GSM/CDMA to LTE/EPC Diameter-based networks, they are encountering a major decision point. With manySignal Transfer Point (STP) vendors exiting the market or reaching End of Life/Support for their products—“What do I do with my SS7 Signaling Transfer Points?”

stp-replacement-questionsIn this post we will discuss important issues that need to be addressed in order to maintain the viability of the existing Signaling System No. 7 (SS7) Signaling infrastructure while migrating to Next-Generation Networks.

Since the start of deployment of the SS7 networks in the mid 1980s, there have been numerous vendors of Signaling Transfer Points (STP) including most switching equipment vendors and other specialized suppliers. With the maturity of the network, there has been consolidation and attrition in the STP market.

Today the number of STP suppliers has dwindled to 4 or 5 vendors, some of which are quite small. The attrition in the STP market and the need to maintain the integrity of the SS7 network is causing major concern to service providers.

These concerns/questions will be discussed in the remainder of this post.

End-of-Life

As defined by Wikipedia — End-of-life (EOL) is a term used with respect to a product supplied to customers, indicating that the product is at the end of its useful lifetime. At this point, a vendor will no longer market, sell or sustain a particular product and may also be limiting or ending support for that product.

At the time when vendors make an End-of-Life announcement, service providers must ask themselves several questions:

  • Can I continue to use the existing STP equipment until I migrate to Next-Generation Networks (IMS or LTE/EPC/Diameter)?
  • How long will I have to maintain the existing SS7 network?
  • Given that this product is no longer a focus for my vendor, what happens to my ongoing support?

Major Upgrades

Some equipment vendors are announcing major equipment upgrades (that can be very costly) required for their customer to remain on support contracts. This is being driven by proprietor nature of the hardware platforms and the ability to supply required components, or simply the vendors desire to get the most revenues out of a mature and declining market.

When vendors announce these major upgrades, service providers are forced to answer the following questions:stp-replacement-question1

  • Should I implement the upgrades or can I run my network without support until I migrate to Next-Generation Networks (IMS or LTE/EPC/Diameter)?
  • Should I replace the existing STPs?
  • What is the Total Cost of Ownership for the replacement STP?

Ongoing Support for SS7/STP

Along with the end-of-life discussed earlier, ongoing support for the SS7 network and the associated STPs is a major concern for the service providers. These support issues are both hardware and software. Questions that arise for service providers regarding ongoing support should include:

  • Has my STP equipment vendor announced end of support?
  • Can I continue to run my network without vendor support?
  • Has my equipment vendor announced an upgrade program to remain on support contracts? If so, how much does it cost?

stp-replacement-question2Evolution to Diameter

The next issue to be addressed is the evolution to Next-Generation Networks (once the decision has been made to upgrade or replace the existing STPs). In order for the service providers to protect their investment by replacing their existing STPs, the STPs have to be able to evolve in providing signaling switching and routing for next-generation networks, i.e. STPs operating as Diameter routers.

Although the SS7 and Diameter-based networks do not typically intercommunicate (except in the case of roaming), Capital and Operational cost savings can be realized if the same platform can handle both SS7 and Diameter.

The questions that service providers need to answer regarding the protocol routing capabilities of the replacement STPs should include:

  • Does the replacement STP only support SS7?
  • Can Diameter Routing capabilities be implemented on the STP platform?

Architecture

In the selection of replacement STPs, architectural issues have to be addressed as they have a direct impact on the cost of implementation and operations. Additionally, these architectural issues can insure that the platform selected provides evolution capabilities and thus does not “Dead End” the service provider in SS7 capabilities only.

  • IP Switching

One of the most important architectural issues to be addressed is the IP switching capability of the selected STP. If internal IP switching is not provided within the selected STP, external IP switches have to be installed, provisioned and maintained especially for the SS7-over-IP (SIGTRAN) deployment.

Questions that service providers need to answer regarding IP switching capabilities of the replacement STPs should include:stp-replacement-question3

  • Does the replacement STP have IP switching within the platform?
  • Does the replacement STP require external IP-switching equipment?

Protocol Routing Engine/Platform

Another important architectural issue to be considered in the selection of replacement STPs is whether or not the internal software design is based on universal protocol switching and routing concepts. These concepts can provide assurance to service providers that as new protocols are defined and implemented within the network, the switching equipment can evolve to meet the needs of Next- Generation Network requirements.

Questions that service providers need to answer regarding routing engines inherent within the STP platform should include:

  • Is the replacement STP designed around universal protocol routing concepts?
  • Is the routing capability of the STP dedicated solely to SS7?

Feature Compatibility

As service providers gain experience with SS7 routing over time, they define required routing capabilities to support their business needs. These specialized routing scenarios can be outside the standard routing capabilities based on:

  • Originating Point Codes (OPC)
  • Destination Point Codes (DPC)
  • Global Title Translations (GTT)

The replacement STPs should have the same routing features and be compatible with the ones that they are replacing.

stp-replacement-question5Ease of Migration STP to STP

After the decision has been made to replace the legacy STP, the next important issue to be resolved is the implementation of the new STPs. This causes concern regarding the ease of migration regarding the following:

  • Implementation without disrupting network services.
  • Implementation without impacting interconnected networks.
  • Cutover without impacting the scarce resource of Point Codes.

Cap and Evolve

One of the key strategies in the replacement of STPs is to co-locate the replacement STPs with the existing STPs and to efficiently migrate the services in a step-by-step approach to the new STPs. This Cap and Evolve strategy allows new growth to be implemented in the replacement STPs. Over time, migrating existing SS7 connectivity to the replacement STPs, thus collapsing the legacy STPs in a controlled and step-by-step approach.

Questions service providers need to answer about the migration strategy of the replacement STP vendor should include:

  • Is the replacement STP implementation strategy step-by-step?
  • Is the replacement STP implementation strategy a “Flash cut?”

Cutover Tools

When service providers and STP vendors start the process of replacing existing STPs, it is of the utmost importance that efficient cutover tools are used. These tools reduce the impact on both interconnected networks and subtending switches.

Questions service providers have to resolve about the cutover tools available should include:stp-replacement-question6

  • Does the replacement STP vendor have STP cutover tools?
  • Do the cutover tools eliminate issues involved with Point Codes?

Simplicity of Installation

Some companies decide to perform the installation of the replacement STP with little or no assistance from the STP vendor, depending on the breadth of experience and the desired involvement of the service provider. The level of complexity of installation determines whether this can be accomplished in an efficient manner by the service provider.

Questions service providers need to address about the installation of the replacement STP should include:

  • Can the service provider install the replacement STP?
  • Does the installation require ‘out of the ordinary’ level of expertise?

Web-based Interface

The implementation of any new technology within the telecommunications network requires that the support and operations personnel, as well as the service provider, be capable of ongoing support and maintenance. The inclusion of a web-based intuitive user interface reduces the training and effort required for the replacement STPs.

stp-replacement-question10Questions service providers need answered about the user interface of the replacement STP should include:

  • Does the replacement STP have a web-based user interface?
  • Is the web-based interface intuitive and easy to use?
  • Does the replacement STP have a command line interface for “power users?”

Vast Network Routing Experience

The selection of a replacement STP and the associated vendor should be based on both the capabilities of the equipment and the experience level of the vendor. The experience level of the vendor is tantamount to the success of the replacement project.

Questions service providers need to address about the experience level of the replacement STP vendor should include:

  • What is the experience level of the vendor?
  • Is the experience related to wireless or wireline, or both?
  • Is this experience US national or international, or both?
  • Is telecommunications signaling the vendors primary focus?

Decision/Implementation Timing

Another important aspect of STP replacement is the timing of the decision to replace the existing STPs relative to the actual installation and implementation of the replacement STP. From the time the decision to replace existing STP is made until the actual turn-up of the STPs is accomplished can range from 6 months to well over a year, dependent on the processes used for vendor selection and the complexity of the SS7 network.

Questions service providers need to address regarding the timing of STP replacement process:stp-replacement-question9

  • Are we going to use a request for proposal process with several prospective vendors?
  • How long does the request for proposal process take?
  • Are a short list and trials going to be part of the process?
  • After the conclusion of any associated trials, what is the installation, implementation and turn-up schedule?

Future Proof

The answers to the questions provided in this post will determine whether the replacement of legacy STPs is simply a replacement strategy or if this strategy is truly a path to Next-Generation Networks. These decisions can lead to an efficient implementation of replacement STPs, thus supporting the most robust, long lived, feature rich signaling protocol in the history of telecommunications, while providing an evolutionary path to the networks of the future.

Source: http://blog.pt.com/stp-replacement?utm_source=linkedin&utm_medium=social&utm_content=1042542

%d bloggers like this: