Voice Nuevo: Edge Focus(FCC ruling)
cimicorp.com
radiowallstreet.com
The decision of the FCC to use its regulatory power to encourage the RBOCs to
deploy advanced digital service infrastructure was a topic
treated in the last three issues. The model of new access networking that initiatives like
SBC?s Project Pronto represents will have a major
impact on voice service directions, and on the service models that will succeed.
The key to the future of voice is the interplay between the FCC rulings on packet
infrastructure and ?line sharing?. The first ruling says that
packet-mode infrastructure is largely exempt from unbundling. The second says that the
incumbent must always be prepared to offer baseband
analog voice on any copper loop to a customer, and to provide wholesale digital
spectrum space above that baseband signal to other providers on
demand.
The first ruling encourages the RBOCs to deploy ATM, as we?ve said, as their new
underpinning technology. This will involve putting ATM
concentrators in the outside plant, linking customer loops to the CO through high-speed
fiber. Because of line sharing, however, these
concentrators will also have to convert baseband analog PSTN signals to ATM cells so
that standard POTS service is preserved even for xDSL
users.
Virtually all residential voice connections are analog, and the great majority of business
voice is likewise (only about 14% of business sites have
digital voice service connections). This means that the broad voice services market will
always pit the CLEC head-to-head against incumbent
traditional voice service?the default service the FCC says has to be available to any
copper customer on demand.
To an incumbent LEC, VoIP creates an unnecessary and highly unfavorable IP
wholesale requirement. To a CLEC, voice over IP, as an
alternative to PSTN voice, has to be justified to the buyer either by cost or incremental
benefit. Since most of the ?cost advantage? of IP voice
is limited to long-distance (and, in most cases, international) applications, it is likely that
VoIP will deploy only as an alternative strategy for
long-distance voice. There, it contributes relatively little in terms of new equipment
opportunity (there aren?t very many IXCs or Class 4 toll
switches).
That leaves features, meaning that any new form of voice technology must provide a
feature benefit against PSTN voice. We believe this
justifies our argument that new-gen voice products really have to be reviewed based on
their feature-creating potential and not on the fact that
they are based on IP, use MGCP, or some other irrelevant technology metric.
Could IP voice deploy in the local exchange due to CLEC activity even if feature
creation were offered in the IP architecture? We are inclined to
say ?No? to that, at least if we define ?IP voice? in the conventional sense. The problem
is that too much of local exchange telephony is
low-margin business, and the cost of duplicating all of the current capabilities of PSTN,
and interfacing to the ILEC (and probably IXC) non-IP
networks, will be excessive.
There is a model that would work, however. If it were possible to create IP-based
advanced voice calling features incrementally for
high-value customers, it might be possible to skim off the high-margin custom calling
service opportunity from the incumbents while leaving
them with the lower-margin local exchange telephone services. That?s a form of voice
business that would be not only financially viable, it
would be downright stunning.
The easiest way to do this is at the source of the voice call, with equipment that either
sits on the customer prem or sits at the end of the analog
copper loop. This equipment could provide a kind of PSTN proxy agent function, acting
as the signaling interpreter for the user?s requests and
forwarding the high-value stuff to the CLEC, while keeping the low-margin stuff in the
ILEC domain. Since it?s clear that the ILEC won?t
deploy such gear as part of their new ATM network infrastructure, the prem approach
seems the most fruitful. In short, voice could become
very edge-driven.
In the new edge service model, the voice network would be viewed as having two
planes?the information or call plane, and the service or control
plane. We believe that the call plane technology will be based on ATM in the access
network in the long term, pretty much no matter who does
the deployment. The control plane is the real issue.
Control plane exchanges are what the SS7 network carries today, and what features are
built on. In the future, if the CLECs are to adopt an
incremental service model to exploit only high-value opportunity, they would have to
build a control-plane network for feature coordination.
That network will almost certainly be based on IP.
This illustrates our problem with most of the VoIP players and even most of the
new-gen telephony players of today. The feature creation
strategies are most often based on SIP, which is an IP protocol operating both control
and call plane activity on an IP network. While SIP
doesn?t mandate this kind of integration explicitly, it does infer it, and SIP-dependent
vendors are not making use of the potential for separating
call and control activity.
With an explicitly separated call and control plane, a CPE device could field telephone
signaling requests from the user and convert those
involving only minimalist communications requirements to an ILEC call. The
remainder?the advanced features?could be sent via the IP
control plane to a feature server for handling. Any of the forms of feature logic control
and execution that we?ve discussed in the past could be
used.
Of course, standard calling could also be provided. We think that special forms of
calling, like conference calling and 800 numbers, might
eventually migrate to the ?advanced services? side of the house. As the revenue and
feature repertoire of the competitive voice provider
increased, more service could be shifted from the incumbent-provided mode to the
self-created mode.
The key element in this new market is that the separation of call and control plane
makes it almost irrelevant what carries traffic, as long as it?s
able to meet basic PSTN reliability and performance requirements. It also creates a
model for service creation that bypasses not only the
incumbent carrier, but any local exchange carrier, or even voice carrier. With this new
model, PSTN service or any form of company voice
service could be overlaid on any access/transport network through the correct feature
software.
Nobody?s doing this yet, folks. Somebody will, both in the vendor and service provider
space.
Data Strategies: What Service Model?
The FCC didn?t require that the ILECs deliver any specific set of services from their
new packet infrastructure, they only required that whatever
service it offered the ILEC wholesale to others. The voice service requirements of the
packet infrastructure can be inferred because of the
requirement to sustain the line sharing capability. No such requirements constraints
operate on the data side, so we have more speculation than
fact in this space.
There are a few points we know, however:
1. The ILECs must wholesale digital bandwidth to a competitor as a service, in the form
of an ATM connection representing the
?data? component of an xDSL connection.
2. The virtual circuit that forms the data access connection can be a PVC, representing
a static, single, ISP relationship, for example.
3. The virtual circuit that forms the data access connection will eventually be an SVC,
allowing the user to switch his xDSL service
from one ISP to another on demand (AOL and Internet, for example).
4. It may be possible to support multiple virtual circuit connections for data services on
a single xDSL access portal.
We view this as adding up to the service-agent-and-service-point-of-presence model of
data services we?ve proposed for the VPN space.
Clearly, if any form of service provider selection is done via SVC setup, there must be a
device either on prem or in the outside access network
that sets up an SVC in response to some sort of IP-level activity. Thus, a service agent.
Likewise, there has to be something at the edge of the
ATM access network to receive an SVC setup and signal the user?s presence in IP
terms, perhaps with a DHCP request. Thus, a service point
of presence (SPOP).
But the details of the model are still too hazy to define. The biggest question is the
number and nature of the data SVCs that can be set up.
Specifically:
1. How many data SVCs can be active at a time?
2. What range of service parameters can be supported on an SVC?
3. Can users set up SVCs to each other in the access network, or only to a SPOP?
4. Can SVCs be forwarded, transferred, etc. in the way defined by the ATM
standards?
5. Will an NNI SPOP be permitted? Could it be prevented?
If it is possible to support multiple data SVCs at once, then IP VPN services could be
offered based on an Internet-plus-VPN-increment model,
with the CPE device screening packets to determine wither the packet was to be
forwarded to the default ?Internet? path, or to another
IP-capable network that would forward the packet to the destination with special
security, performance, or both. Without support for the
multiple SVCs, any special VPN handling would have to be applied by the VPN
SPOP, and the VPN SPOP would also have to integrate VPN
packets with Internet packets so they?d arrive on a common connection.
The number of SVCs is clearly an issue because it would relate to the number of VPNs
that could be integrated with the customer IP flow by the
CPE. A small number would mean that either the VPN sales potential would be limited,
or that SPOPs would be required for integration.
We think that the market overall would benefit from having ILEC support for a large
number of data SVCs, even if those SVCs were limited to
customer-to-SPOP rather than customer-to-customer. We also think that this will
eventually be the direction the ILECs will take, but it may be
that support for versatile data SVCs will await the ILEC creation of their data
subsidiaries.
More selfishly, SVC flexibility would promote a facility view of VPNs that would favor
the incumbent providers over the ISPs. For that reason
alone, the ILECs should be motivated to adopt the flexible model within two to three
years.
Conclusion
The FCC ruling on packet infrastructure and the subsequent ILEC movement toward an
ATM access network seem to promote both our
new-gen voice position and our VPN position. At least, the kind of local exchange
network that these developments portend would be more
readily exploited by the voice/data models we?ve described.
Unfortunately, the media treatment of these developments has set a new
standard for insightless journalism. We?ve found that a surprisingly
large number of vendors are completely unaware of what?s happening, and thus
unlikely to be positioned for the truth. We attribute this to the
fact that most of the startups launched in the last year are at least somewhat
out of position with respect to these developments, and their VCs are
unwilling to accept the cost of restructuring the product. Hence, they are trying
to maintain the fiction of a more IP-centric market model while
they try to IPO their portfolio and bail out their positions.
|
