In Re: )

)

PUBLIC FORUM: )

)

COMPETITIVE ACCESS TO )

NEXT-GENERATION REMOTE )

TERMINALS )

Volume: 1

Pages: 1 through 137

Place: Washington, D.C.

Date: May 10, 2000

Before the

FEDERAL COMMUNICATIONS COMMISSION

Washington, D.C. 20554

In Re: )

)

PUBLIC FORUM: )

COMPETITIVE ACCESS TO )

NEXT-GENERATION REMOTE )

TERMINALS )

Main Hearing Room

445 12th Street, S.W.

Washington, D.C.

Wednesday,

May 10, 2000

The parties met, pursuant to the notice of the

Commission, at 1:05 p.m.

APPEARANCES:

NEIL RANSOM, VICE PRESIDENT AND GENERAL MANAGER

ALCATEL

DAN WIGGER, DIRECTOR, NETWORK ENGINEERING

ATG

C. MICHAEL PFAU, DIVISION MANAGER

AT&T

CHARLES KIEDERER, DIRECTOR, TECHNOLOGY PLANNING

BELL ATLANTIC

WILLIAM McNAMARA, RESEARCH DIRECTOR

TECHNICAL ANALYSIS AND SUPPORT - TRANSPORT/ACCESS

BELL SOUTH

GARY BOLTON, VICE PRESIDENT, PRODUCT MARKETING

CATENA NETWORKS

JOHN REISTER

AVP, ADVANCED TECHNOLOGY

COPPER MOUNTAIN

APPEARANCES (Continued):

DAVID ROSENSTEIN, MANAGER OF ACCESS TECHNOLOGIES

COVAD

LINDA MANCHESTER, ACTING VICE PRESIDENT,

ACCESS NETWORK MARKETING

LUCENT TECHNOLOGIES

BILL BUCK, PRODUCT MANAGER

NOKIA

WAYNE GETCHELL, DIRECTOR

SUBSCRIBER ACCESS SOLUTIONS

NORTEL NETWORKS

MICHAEL OLSEN

VICE PRESIDENT AND DEPUTY GENERAL COUNSEL

NORTHPOINT

PHILIP KYEES

BUSINESS DEVELOPMENT MANAGER FOR DSL PRODUCTS

DIVISION

PARADYNE

STEPHEN BOWEN, BLUMENFELD & COHEN

RHYTHMS NET CONNECTIONS, INC.

WAYNE MASTERS, SENIOR VICE PRESIDENT

SBC BROADBAND SERVICES

SBC

[P R O C E E D I N G S]{.underline}

(1:05 p.m.)

MR. VARMA: Good afternoon, everyone. Maybe it is time for us to get
started. My name is Yog Varma. I am the deputy chief of the Common
Carrier Bureau. I also belong to a growing breed of deputy bureau
chiefs, if you know what I mean. First me and Bob Atkinson. I wonder who
is next.

(Laughter)

MR. VARMA: On behalf of the Commission, the Common Carrier Bureau, the
Office of Engineering and Technology, the Network Services Division, and
the Network \-\-- Division, I am pleased to welcome you all to this
public forum and roundtable discussion on next generation networks and
remote terminals.

We thank you for accepting our invitation to this forum to discuss and
inform us on emerging next generation network issues surrounding remote
terminals. As you know, we are currently gathering information to help
us evaluate the type of network design on the deployment of a range of
services in the competitive environment. Our goal here is to ensure that
incumbent telephone companies, their separate affiliates, or competing
CLECs are able to deploy next generation networks to offer advanced
services in a rapid, broadbased, and cost effective manner on a level
playing field for the benefit of consumers.

We understand that there are a host of technical issues that arise when
multiple carriers desire access to the same facilities. In order to
enhance our understanding of these issues, we have set up this
roundtable discussion with representatives from various sectors of the
industry to address the technical issues that arise when remote terminal
facilities are made available to competing carriers for the provision of
advanced services for consumers.

We hope to better understand how to allow competitors access to next
generation remote terminals and the associated technology while
encouraging incumbents or the separate affiliates to offer advanced
services to their customers in a manner that does not impair the
networks.

Through this roundtable and any future proceedings, we hope to further
Congress\' framework and achieve the FCC\'s mission for an open and
competitive advanced services marketplace and to ensure that such
services are available to all \-- and I underscore the word all from a
variety of different sources, each of which has a different ‑- has a
fair opportunity to compete.

If this also leads to accelerated investment in the underlying
infrastructure by competing suppliers, that for me personally would be
icing on the cake. In this regard, I hope our discussions focus not only
on the issues surrounding delivery of ADSL to DLC and end users, but
recognize as well the rapid technological developments, rising customer
expectations, and their voracious appetite for more and more bandwidth.

As a matter of fact, you may recall a few years ago, there used to be a
commercial from Campbell Soup Company about not enough clams in clam
soup. And the commercial was, more clams! more clams! more clams! I hope
soon there will be a day when we will be saying more bandwidth! more
bandwidth! more bandwidth!

I agree with my friend Paul Lacouture (phonetic), group vice
president/Network Services at Bell Atlantic, and Tim Laehy (phonetic),
chief financial officer at Cobell (phonetic) Communications that DSL is
not the endgame. It is only an entry strategy into the vast and
ever-increasing data services market. The story is just beginning to
unfold. Please stay tuned.

I would now like to turn the discussion over to Staci Pies (phonetic),
who is the deputy chief of Network Services Division, who will get the
discussion underway. Staci?

MS. PIES: Thank you, Yog. I appreciate everybody coming out here today,
and I want to especially thank Jennie Kennedy from the Network Services
Division, who helped plan this forum and made sure that everybody was
able to be here and have this discussion today.

As Yog mentioned, we have people here from the Network Services
Division, the Policy Division, and the Network Technology Division of
OET. And we have panelists from the incumbent local exchange carriers,
competitive carriers, and manufacturers. And rather than going through
and introducing everybody, I am just going to ask that the first time
that you speak, that you please introduce yourself and state the name of
your company.

As you all know, the deployment of remote terminal technology and
digital loop carrier equipment to consolidate voice traffic of remotely
located customers for transport back to the central office is not new.
In fact, incumbent LECs have been using digital loop carrier technology
for over 20 years to reduce costs and space requirements of providing
plain old telephone service to these customers.

However, today, in order to meet the demand for high speed data
services, carriers must also find a cost- effective way of providing
advanced services to these outlying areas. So in order to meet this
demand, some incumbent LECs are beginning to redesign their networks by
deploying new technology in their remote terminals. These next
generation remote terminals ‑- in these next generation remote
terminals, the data traffic and the voice traffic share the same back
plane, are aggregated by the system, and may share the same transport
facilities back to the central office.

As Yog stated in his opening remarks, we are here today to talk about
the technical and operational issues that arise as competitive carriers
seek to provide advanced services using the incumbent LEC
next-generation remote terminals. As most of you know, we have had a
series of meetings over the last few weeks to get better background on
these issues, and we have found these discussions to be very
informative. We are hoping today that an open discussion where positions
and ideas are tested by different members of the industry will enable
the Commission staff to reach well-supported conclusions on many of
these issues.

I just want to mention that we have significant ground to cover today.
And we hope that people will be able to express their points of view
without engaging in any lengthy presentations. We do realize, however,
that it might be helpful for parties to use some sort of presentation.

We do have a chart that we have included in the handout. Hopefully, you
all have a copy of that. It is very, very simple. But if you do need us
to have that on the screen to explain some of your points, just please
ask for that FCC chart.

I also want to emphasize that we are not looking for a particular
outcome today. This forum is not directly related, and we don\'t intend
to discuss, legal and policy issues associated with any particular
ongoing proceeding before the Commission right now. Instead, again, as
Yog said, we are looking for information that will allow us to have both
a competitive and broadbased deployment of advanced services and
telecommunications services.

We want to welcome questions or comments from the audience. And we just
ask that you use your discretion and approach the microphones at an
appropriate time, again identifying yourself and your company before
asking your questions. And we are just going to start today with a few
basic questions that will lay the groundwork, give everybody a basic
understanding of remote terminal technology. And then we\'ll proceed
with the questions that we have provided the participants.

So, Johanna will start.

MS. MIKES: Johanna Mikes. I am with the Common Carrier Policy and
Program Planning Division. Before we jump to the highly technical
issues, I just wanted to start with eliciting some basic facts about the
remote terminal equipment that exists in the network today as well as
what is being planned for the future. And so I would like to just ask
the incumbent carriers to describe what type of remote terminals and
equipment is deployed in your network and is in use today in terms of
the numbers, the volume of remote terminals, the percent of your
network, or the percent of customers served out of remote terminals, the
size and dimensions of the types of remote terminals, and what types of
customers are being served from those.

So if you could talk about what exists today, and then we\'ll get to
some of the future plans.

MR. KIEDERER: Charlie Kiederer with Bell Atlantic. In terms of the
specifics, I\'d rather address that not so much in terms of numbers but
in terms of the type of equipment that we have employed, although I will
give some general numbers that we have. Typically deployed in our
network, we have equipment ranging from the likes of Slick 96 (phonetic)
carrier to Slick series 5 carrier to light span digital loop carrier and
some Nortel access nodes, digital loop carriers. Those are probably
primarily the major versions of equipment that we have deployed in the
network.

In round numbers, approximately 18 percent of our lines are served on
digital loop carrier. As far as size, which was the other part of your
question, sizes would range all over the map, depending on what ‑- how
many lines you are serving at a particular remote location, from
relatively small units to units that can serve upwards of 2,000
subscribers.

MR. MASTERS: Very similar ‑- Wayne Masters with SBC. We have roughly
around 35,000 remote terminals deployed in the network today. This the
13 states. As you will describe later, they appear in three forms. You
have CEVs, HUTs, and cabinets, and they are quite different. We have the
older Lucent Slick 96 series 5, very good vehicles. We have the Reltech
(phonetic). We have the heavy imbedded base, the light span. And it
differs somewhat by the company, the four companies. And we have the UMC
1000.

We may still have some Nortel in service. We have a variety. Every
company has a history. Probably there will be an exception to almost any
rule. You\'ll find something buried out there somewhere.

We run about 25 percent of our customers today through remote terminals.
They generally serve, obviously, your far-out ‑- generally those
distances beyond 18,000 feet, which gets you in your business park
subdivisions, but in some metro areas like Chicago, it might be a mile
away. So it all depends what the application is.

That\'s about it.

MR. McNAMARA: I\'m Bill McNamara with Bell South. We probably have ‑- in
fact, I know we have the largest single installation of DLC in the
United States. We have right at 40,000 remote terminals serving almost 9
million lines off of those terminals. The mix is pretty much as the
others have mentioned. We probably have fewer NGDLC, having begun to
deploy that technology a little bit later, something over a thousand
terminals serving something over a million subscriber lines, close to
another 8 million in old technology.

The mix between CEVs and cabinets is approximately 1,200 CEVs and HUTs
to the rest, based on cabinet architectures, the sizes, as previously
alluded to, from the size of maybe a very large trash can to the size of
a very large limousine.

MS. MIKES: And if I could have again the same group of incumbent
carriers discuss what is planned for the future in terms of remote
terminal equipment and the types of remote terminals, and again the same
basic information, the percent of your customers that you anticipate
will be served, the size and dimension of the new remote terminals being
deployed, what types of customers you are reaching, and what is involved
in upgrading or replacing the existing equipment, if that is in your
plans.

MR. KIEDERER: From a Bell Atlantic perspective, the issue of deploying
DLCs on a going forward basis is done on a situation by situation basis.
They are typically provided for relief for new subdivisions. We have a
somewhat different demographics, I think, in the Northeast region in
terms of the density of the urban wire centers that we have where we
don\'t use a lot. As you have heard, we have probably less digital
carrier than the other two incumbents represented here.

But those would be designed per standard engineering practices,
depending on what the relief is for, what kind of services are required,
how many living units are to be handled by that particular remote
terminal. So I can\'t sit here and say that we have specific plans for
numbers of remote terminals on a year by year basis.

MR. MASTERS: Basically what Charles said, on an ongoing business it is
basically the same. But as everybody in the room is well aware, we have
a very large initiative going on to try to put a lot more remote
terminals in our network.

I\'ll give you some follow-up numbers. A while ago, we talked about the
percentage. Today, after our initiative, the numbers are about the same.
About 40 percent of our households will be served out of CEVs and HUTs,
without about 60 percent being out of cabinets, to give you a flavor.
And those numbers held about the same before and after. We said earlier
we have about 35,000 remote terminals, and they were adding another
roughly 13,000. We\'re upgrading 7- to 10,000 of existing ones to
provide a broadband service, next generation DSL, and actually a
broadband capability to the network bay.

We\'re upgrading two, and we\'ll possibly do three, of our existing
vendor\'s technology. That is changing by the day. We are looking at
every opportunity or method of doing that, from total replacement to
upgrading to side by sides. Every one of those turns out to be more of a
individual engineering decision, basically when you look at the exact
environment.

We are basically going to feed the plant beyond our 12,000 kilofeet loop
in our major wire centers with an overlaid network, with the idea being
that we will shorten the distance of the remaining copper loop to 12,000
feet or less.

The standard architecture design for remote terminals hasn\'t changed.
Normally, it has been about 9 kilofeet behind a remote terminal. It
varies some by company, but not much. And basically, the fundamental
design has not changed. We are just putting more of those areas in. We
are not removing any of our existing technology or plant. All we are
doing is adding additional capacity out of these. We\'ll use them as an
overlay growth vehicle. We\'ll use our existing copper plant up for
services it supports, i.e., plots. Then we\'ll take growth on the RTs
for all service.

As a customer converts over to our broadband service, we are offering ‑-
are going to extend the offer. They will be moved over to the RT. Once
they are there, they will be served from the RT. So it is an overlay
growth vehicle, very much like we have extended our network over the
years.

Over the history, you will find copper first, then you\'ll find a
digital loop carrier. You may find two or three vintages of digital loop
carrier. And you\'ll find its natural, just a growth. It is a feeder
relief plan, essentially.

MR. McNAMARA: In Bell South\'s case, all of our growth today is going on
next generation products. We aren\'t deploying any old technology to DLC
any more. It is all next generation products with copper feeder. Or in
the architecture of choice in Bell South, the new growth is actually on
fiber distribution. We deploying about 100,000 plus lines of capacity a
year, 100,000 linear units are being passed per year with fiber
distribution right to the curb. We expect to accelerate that over the
next few years.

We anticipate adding ADSL or DSL capability to existing vehicles. We are
not adding additional DLC ‑- our next generation products at existing
sites purely for a DLC distribution vehicle. Where something other than
an existing product is needed to deploy DSL, we are using dedicated
DSLAMs for that purpose.

MR. REEL: I\'d like to ask a follow-up question for Bell Atlantic and
Bell South. Are you also planning to leave the existing copper and
maintain it and make it available for sale? Or will you be just letting
it \--

MR. McNAMARA: We normally, we actually do an overlay in there at a DLC
at a site with fiber feeder, we would typically leave the copper in
place unless the copper is in such bad shape that it has to be removed
or terminated. The issue for competitors for providing access to that
capability is yes, it is certainly available. The problem is there are
serious spectrum management issues associated with using that capability
if DSL is also deployed at the RT site.

MR. KIEDERER: Just to add to that as well, typically where fiber digital
carriers put in as a growth vehicle, the copper would be left in place.
In areas where you are looking to rehabilitate bold copper, the plan in
many instances would be to remove the old copper because it is a
maintenance headache. That is why you want to take it out to begin with.

We, under the current guidelines, to the degree that there were ADSL
unbundled loops on that copper, certainly would intend to leave it in
place at this point in time. However, that results in the issue now of
maintaining dual plant fiber and copper and the associated costs and
cost recovery issues associated with keeping dual plant in service.

MR. KEHOE: I\'d like to direct a question to the three block
representatives and to SBC first. How much unused space is there in your
old RTs and will there be in your new RTs?

MR. MASTERS: I\'ll address that in two groups. Let me address it, first
of all, in CEVs and HUTs. About half of our CEVs and HUTS exist today,
about again the percent growth we said earlier. We have a higher
percentage of access lines than we do actual locations in these HUTS. In
the existing CEVs and HUTs, there is some space, and it varies
absolutely case by case. In new ones going forward, as we publicly have
said, we have elected to build additional space in all new CEVs, and
that is going forward, particularly in our initiative project, to allow
colocation roughly three to five CLECs.

We have done quite a bit of configuring. We have got some forecast
information on that. It is basically the next size up. Now that is
restricted by right of way, things, the physics involved in the site.
That is cost us about \$15 million dollars.

In the cabinets, the cabinets are being pushed, as Bill said, much, much
closer. We said 12,000 feet. That is our longest distance. Some of the
cabinets are going in as close as 2,000 feet, especially in the Bell
Atlantic Ameritech states.

In cabinets, there generally is not much space, if hardly at all. You
may find a place that you could put a single rack and in some. It varies
cabinet by cabinet. It depends on how it was built and what it was built
for. There is some in some cabinets. All those spaces are available for
colocation. But one of the reasons we offered them rather than the
service offering is that ‑- our planning in offering is we recognize
that there is not going to be space at every cabinet. And we could find
no legitimate scheme economically to provide space in those cabinets.

MR. KEHOE: Would either of the others like to elaborate?

MR. KIEDERER: Well, yeah, perhaps just to add a few comments to what
Wayne had to say. I think you have to break this up into two pieces. One
is what do you have available in the existing, and what might be
available in anything new coming down the line. You have got to remember
that the existing remote terminal structures were planned, engineered,
and deployed to serve POTS capability. They are designed for that
purpose. That is why they were put in. Any space that may be available
in them were to cover the POTS growth for some period of time, usually
in the range of five years.

While we do have space in some of those ‑- and I would say it is
probably less than 30 to 40 percent. You have got to remember that that
space was intended to be used for POTS kinds of services, for growth in
that particular carrier serving area. To the degree that you use that
space for something else, you now have to deal with the issue of how do
you handle your POTS growth in the future.

We will, you know, as of May 17th under the union remand, accept
requests from competitive local exchange carriers for colocation at
remote terminal sites, and we\'ll deal with those on a site by site
basis.

MR. MASTERS: Okay. I\'ll give a short follow-up to Charles. Obviously,
the space available has to be usable space. We are finding with DSL that
cabinets were originally designed for POTS. DSL has a much higher power
dissipation, roughly two or three times as POTS. We are being lumped in
their upgrade program as much by power dissipation as we are by physical
space. So it becomes a bigger factor going forward than it has been in
the past.

MR. McNAMARA: I don\'t think there really is much to add to that. That
is basically the same situation in Bell South, very little space in
cabinets, a fair amount in CEVs and HUTs. And we have offered to make
that available to collocators in basically the same basis as colocation
in central offices.

Cabinets are a serious problem. They actually require special
engineering to deploy equipment that is not delivered with the original
cabinet from the supplier of that engineered installation.

MR. SICKER: I\'m Doug Sicker with the Office of Engineering and
Technology. Before we launch into the questions, I\'d like to ask if any
of the vendors or the competitors would like to respond to what the LECs
have just gone through. Please.

MR. BOWEN: Steve Bowen, Blumenfeld & Cohen, for Rhythms Net Connections.
We in fact are involved with SBC in a couple of cases about this right
now, one in California. From our perspective, no terminal really is the
new central office. That is, we really need to be there. Colocation is
required there. We need to be there whether that is a cabinet, a HUT, or
a CEV.

In California, I think 74 percent of the current RTs are cabinets. Now
they may not be the small cabinets that are being deployed on a going
forward basis, but they are the smaller of the three of the three
flavors of RTs.

We think it is very, very important that as these new network topologies
roll out that there be space for everybody out there. We are very much
in favor of pushing fiber out as far as we can into the neighborhoods.
We think it is a good topology that allows all of us to reach a lot more
people with a lot more broadband services. But I think the problem that
we see really focuses on what these gentlemen have said, the cabinets.

I think the going forward technology will be cabinets. And it is not
just the mesa type cabinets that, for example, SBC has been deploying in
the past. It is new cabinets that ‑- some people call them shrink wrap
cabinets. That is, it is cabinets that are designed and built to house
integrated equipment of only a single vendor. And I understand the
economics of that, and I can understand the attractiveness of setting
down a cabinet with a small footprint.

But the problem that creates for competitors is in the configurations
that we have seen that are rolling out right now ‑- and I won\'t talk
about Neil\'s company right off the bat, but the Alcatel 2016 is one
example. This is a very nice unit that sits down on a pad and has
already populated chassis and plug-in cards, and there is no space in
there. We agree with that. There is no space in the current
configuration for anybody else\'s equipment to reside.

So even though that might be a good kind of architecture and a good kind
of RT configuration in the monopoly world, it is not good if you want
CLECs to be able to have other vendors\' DSLAMs in there, other kinds of
equipment in there. And from our perspective, I think it is fair to say
that all we are asking for is the right to compete even up with Bell
Atlantic, Bell South, SBC, U.S. West.

We just want to be able to have our equipment and our vendors\' choice
of equipment be able to live out there as it must because as we all
know, even though I agree with Yog that this is not about DSL, DSL is
right now the serving technology for broadband services over the last
2,000, 9,000, whatever number feet of copper you have. You really need
to use the copper to get to the premises, whether it is residential or
business, and you have got to use DSL to get there. And so you have to
DSLAMs out there at the end of the copper.

MR. SICKER: I agree with you. But what I really don\'t want to happen
here is for everybody to stress the competitive importance of this. We
recognize it. That\'s why we are having the meeting. And I take your
latter point. I agree with it. So let\'s launch from there and go into
how do we do this.

MR. BOWEN: Okay.

MR. SICKER: How do we ensure that we can have this sort of diversity of
equipment.

MR. BOWEN: We think that it is possible ‑- for example, right now, yeah,
you have got CEVs out there, and you have got HUTs. There is a couple of
sizes of each of those. Both of them are actually fairly large, and they
use rack mounted equipment, as we all know. And, yes, they were designed
to serve POTS.

But what is really happening out there is that the technology is
shrinking. Even the POTS serving technology is getting more and more
efficient. The form factors are decreasing. And so you can actually fit
‑- if you take out the old stuff and replace it with new stuff, even for
POTS, you can create more space in those existing larger kinds of
configured RTs.

So for CEVs and HUTs, these are ‑- they had to be air conditioned
because the generation of technology that was deployed in those
facilities required conditioned space. The cabinets of today, they still
require heat dissipation, but it is done by fans as opposed to by having
controlled air conditioning spaces.

So we think it is possible under any configuration, whether it is a CEV
‑- I appreciate SBC saying they are going to build new CEVs that have
extra space for competitors\' equipment. That is a good thing. We think
that is what they are supposed to be doing. But it is even possible to
deploy even the cabinets in sizes that are big enough so that you have
some extra space for competitors.

I\'m not talking about, for example, the ‑- I\'m sorry, Neil. The
Alcatel 2016 is a very nice unit. It has got basically three racks on
each side. If you had a unit that had four racks, right, and add an
extra two feet to the cabinet, that would give us enough space to
collocate what we call kind of pizza box type equipment. These are 2
inch tall DSLAMs, basically, that fit in racks. It is possible to do
that. And you can do that by saying I\'m not going to buy a cabinet that
only has three racks wide. I\'m going to make it four racks wide or five
racks wide. And these choices can be made right now because right now is
when the new RTs are being rolled out.

MR. SICKER: So to summarize, you think RTs that are being deployed
should be deployed in a large size to accommodate, and those that are
the older generation should be ‑- the gear that is in there should be
taken out and replaced with ‑- you said that earlier, didn\'t you?

MR. BOWEN: Yeah.

MR. SICKER: You agree with that, or you \--

MR. BOWEN: Well, what I mean to say is ‑- I\'m not saying that the RBOCs
(phonetic) should rip out existing equipment just to rip it out to make
space. That is not our suggestion.

MR. SICKER: If the need is there, you believe that it should be done?

MR. BOWEN: As they change out their equipment for newer generation
equipment, the form factors tend to be smaller. And so there tends to be
\-- not in every case, but in many cases, there is space even in
existing CEVs and HUTs for additional CLEC equipment. And as they build
new CEVs and HUTs, they can obviously size those because they know that
we want to collocate in those as well.

So from our perspective, the right answer is always let\'s make sure
there is room enough for everybody to be there, whether it is an
existing one or a new one.

MR. SICKER: Okay. John?

MR. REISTER: John Reister, Copper Mountain. I would like to ‑- I concur
with many of Steve\'s comments. Wayne, you made a statement that there
is no economic way to add space to existing cabinets. And I guess I
would want to probe on that in terms of, you know, have you looked at,
you know, colocation, nonrecurring and recurring revenues from CLECs
that you could get from that space, the additional revenues you get from
the broadband services that you are providing in that in terms of ‑- and
then I don\'t know per se what would be involved, you know, in adding a
rack to a cabinet, how difficult that is and why it is not economic.

MR. MASTERS: Two or three things. First, you have to recognize that well
over half the RTs and cabinets we are ever going to deploy are already
out there. They are in place, where they are, they are. Particularly in
California, Steve\'s territory, is we have cities with unique mindships
about what should be placed in the right of way and the condition of
rules. Some say things can\'t be more than 37 inches tall. Any flavor of
restrictions you want to have, I can find a city that has them.

As we are pushing these deeper and deeper into the network, we are
getting closer and closer into the neighborhoods, we are running into
more and more restrictions and city and styles. People have gotten very
creative in how they configure these things, hide them, shrub them, all
those things. So even what we decide in this room, we still have to deal
with the cities and right of ways.

So can you make them bigger? You can build anything. You can build a
football field sized something. I don\'t think we want to put 40- or
50,000 of them out there.

Now can you make an existing cabinet bigger? It is in the existing
system. Making one bigger going forward defeats the plan of pushing
deeper into the neighborhoods because I am going to run into more and
more restrictions. And then even we did, you would only have a certain
percentage of your locations. You would never have a ubiquitous cover of
a neighborhood because half of those locations already exist.

That\'s why we took the approach of taking all of the embedded base and
existing ones and making the space available to all through a service
offering. Basically, you put technology in, you make that technology
available to everybody in equal terms and conditions, and you live
within the space you have or can obtain.

Also, it would take a great deal of time to augment the existing ones,
our new ones going forward. And if you also say, well, wait until all
new ones going forward, your market coverage is going to be very slow. I
don\'t know that people in this room can wait to cover this market with
cable out there.

So, yeah, we have looked at maybe the physics, not the economics, of how
would it cost more than an engineering standpoint, of what it would cost
to enlarge a box, and if so, how many CLECs you can put in. In our last
industry forum in March, there were 34 CLECs. I have no idea of the
number of manufacturers they would require. Or say there was only five
different manufacturers. Would they even share?

We could not come up with any scheme. You might get one or two in a
location, but how do you get 34 in a location on every street corner?
Some people have used the word village. If you have seen 15 newspaper
racks on a corner somewhere, how do you live with that in the
environment? It may be theoretically possible. We just don\'t think it
has been possible in the communities we live in and work in to do that.
That\'s why we elected CEVs and HUTs. They are underground, they are
easier. They are kind of big, 20, 25 percent more doesn\'t seem that
large going forward. But that also doesn\'t help in the CEVs and HUTs I
already have.

So half of what you are going to deal with is already out there, if not
more.

MR. REISTER: Just to respond, I think you\'ll find that the newer
generations of equipment come down in both space and power. So it does
seem like one of the principle challenges then is in the existing \--

MR. MASTERS: Communications.

MR. RANSOM: Let\'s assume that there are no responses to that, okay?

A follow-up to what the network operators had said earlier, another
trend which may be interesting to include in this we have seen ‑- and my
name is Neil Ransom from Alcatel ‑- is that the sizes of the RTs are
getting smaller as time progresses, as the technology of doing digital
carrier and fiber optics gets more economic, it is feasible to put fiber
deeper and deeper in the network, therefore each RT serves fewer numbers
of homes. Perhaps the extreme are some of the things that Bell South has
been deploying with only four to eight homes sharing a given fiber to
copper interface.

I think that is important to consider as we are thinking about
colocation. It is one thing when we are talking 2,000 lines, something
else if we ever talk about four and eight line, what would be economic
and sensible in those kind of environments.

I guess I would agree that we do shrink wrap our equipment, and not just
in the size of the cabinets ‑- and this is something else we have to
consider as we talk about this today ‑- there is the issue of the amount
of power that is available. All of these have to have battery backup to
provide continuous service, even when the power goes off. And that is
expensive to do, and we put the least amount necessary in order to serve
the equipment. And also, the power dissipation, which is also a problem
in RT cabinets. Since we don\'t have air conditioning, we have to design
the equipment at the minimal power so that it can exist in these
cabinets that are out in the sun.

So when we talk about what is available in these cabinets for
colocation, don\'t forget the power which would have to be considered as
well as heat dissipation issues as well.

MR. SICKER: Yeah. We are going to get into those issues. But on your
earlier point, I don\'t want to digress into kind of the economies of
scale of when do you not create colocation. But I get the point that you
were suggesting, is at some point you get down to four or five or eight
or twelve, it just doesn\'t make sense to try to collocate? Is that \--
it is just going to be one provider probably?

MR. RANSOM: Well, it is certainly more of a challenge to do that
economically. And we would have to recognize because we certainly serve
the CLEC market as well as the ILEC market in trying to understand
colocation. That becomes even a more challenge to do that economically
if you have a small line size, where among those four to eight homes,
you are lucky if you are to have one customer there at all.

MR. SICKER: Right. I was passed a note to ask the speakers to actually
speak into the microphone because apparently the people aren\'t hearing
in the audience.

On Wayne\'s discussion of platforms as a means of getting broadband
services, let\'s jump to the questions headed number two, purchase of
advanced service platforms for incumbent LECs. We can probably just jump
down to what are the pros and cons of this situation. I would like to
actually turn it over to the competitors\' side a this point. Mike?

MR. OLSEN: Northpoint Communications. It seems to me from the
competitive carriers ‑- facilities based competitive carriers that no
single solution is going to serve all, but there will be some variety
because there are limits on each. For example, on colocation, there is
going to be technical feasibility and economic feasibility limits, both
from the incumbent\'s ability to collocate and the competitor\'s ability
to finance. For example, if you are passing four homes, you would have
to have all of them to justify such a deployment.

So that is an alternative. It is an important alternative. But the broad
band you need is also an important opportunity for ensuring that end
users can get a variety of service providers. And we have as an industry
made some objections to the broadband UNI. Most importantly is that that
broadband UNI, that is, the facilities that underlay that, for example,
the Alcatel platform, has fairly robust capabilities. Those robust
capabilities include the ability to support some of the services that
today only the DSL CLECs are pushing on. And our concern about the
deployment of the broadband UNI as presently styled, at least in the one
example we have from SBC, is that it limits some of those opportunities.

So in the broadband UNI area, we think it is a good idea. It certainly
has some pros in making sure that end users can get a variety of
services. But it shouldn\'t be hobbled. That is, even though the
incumbent may choose, for example, not to do voice over DSL or to
support high speed out of that platform, we like that platform in a lot
of respects. We think we might even like it better than you because we
want to use quite a bit of it.

So we want to make sure that all of the capabilities of that equipment
are unleashed and the competitors, whoever they may be, including the
ILEC and its affiliates, can exploit that to bring innovative services
to end users.

MR. SICKER: I just wanted to ‑- I have two things. First of all, we are
trying not to use the term broadband UNI here because it is not a UNI.
Second, I probably should have explained what a platform actually is. In
this case, what we are ‑- particularly to the audience. I think everyone
around the table understands what this means. But what that option
provides is a method for the competitors and the data affiliate to be
able to purchase a platform to provide band services from the incumbent
and use the incumbent facilities. So rather than collocate, obviously,
this means getting something from the CO side of the connection.

So with that \--

MR. BOWEN: Doug, could I add something?

MR. SICKER: Please.

MR. BOWEN: Okay. This will be a bit more technical. Let\'s take a
hypothetical RBOC from San Antonio, but not talk about any particular
vendor.

(Laughter)

MR. BOWEN: What is possible to do right now with, let\'s say, an Alcatel
platform and their ADLU card is to ‑- basically, it is an ATM,
asynchronous transfer mode, serving technology. It is packets. And we
all know that ATM as a technology supports a variety of what is called
quality of service levels. So, for example, you can get a quality of
service level called unspecified bid rate, which gets you Internet
access because it has high delay or high latency potential to it.

That is one kind you can offer. That is one kind we are being offered by
some hypothetical RBOC. But some of the things that Michael was talking
about, for example, voice over DSL, video over DSL, these are all
possible as well over ATM. But you have to have a different kind of
quality of service. You have to have like a constant bit rate which has
lower latency, lower delay, so you don\'t get the conversation with the
moon kind of phone calls.

And so ATM technology has already had these quality of service levels of
parameters specified for a long time. This information is included in
the packet header for every packet that goes out on ATM. And so all you
have got to do is use your element manager, so-called. It is the way you
configure these circuits to say I want no specified bit rate on this
universal circuit, or I want constant bit rate, and there is four or
five or six of these things.

But what you get then is different qualities of services, meaning
different latencies, different delays. And if you use the technology, if
you use Alcatel\'s technology as it can be used, what you can then do is
say I want more than just unspecified bit rate. I want to be able to use
all of these different flavors that the technology allows so I can offer
my customers choices and different kinds of services.

So that\'s, I think, what we are talking about when we talk about how do
you use the platform.

MR. SICKER: That\'s what I said, three.

(Laughter)

MR. SICKER: I should point out it is cells not packets at ATM.

MR. OLSEN: I would make one brief addendum, and then I\'ll pass it back.
One of the important things about facilities based competition is that
there is innovation on two levels. There is service providers. And, of
course, our vendors who we push and cajole to give us new technology so
that we can race it out and put it into central offices, we need to find
a way to bring that to bear on the equipment providers to the incumbents
in the remote terminals, even if it is on the platform. And I think this
has two subparts.

One is unleash the potential. For example, the Alcatel equipment is
capable of a variety of ATM functions. And the next firmware upgrades
and deployments are going to be capable of even more. We\'ll get to IP
multicasting, et cetera. Those should be supported.

But moreover, we need to bring market forces to bear on those equipment
vendors. In the present situation, they are going to have one or two
buyers or three buyers, which would be the incumbents, whereas our
providers have a number of them. And that competition is good and brings
no innovation.

We should find a way to make sure that the market forces ‑- that is, the
CLEC demand, customer demands, and ILEC demands ‑- are brought to bear
on the Alcatel\'s or UMCs either directly by permitting CLECs to
purchase from them and install the new technologies, or through some
forum like OBF or ENRIC (phonetic), which ensures that the incumbents
are responsive not just to their affiliate or their own services, but to
the demands of the customers and the CLECs in permitting those upgrades,
software upgrades, et cetera.

MR. SICKER: I think you have a response to this, so let\'s \--

MR. KIEDERER: Well, maybe just a few things from an engineering
viewpoint to clarify. And I\'ll let our vendor representative add some
things as well, I believe. But in terms of talking about the DSLAM as an
ATM switch, while that has ATM functionality, I wouldn\'t quite classify
it as an ATM switch that can do all of the things that an ATM switch can
do today. But again, I\'ll let Neil talk to that a bit.

But I think the other thing you need to consider from an engineering
perspective is that we have to remember what this was being deployed for
and how much functionality you have got to put into it. And this gets to
the issue of business plans, which is kind of out of the realm of this
forum. But you have got to look at ‑- if you are going to be providing
things like constant bit rate, which I don\'t think you can do today, at
least out of the existing RTs that I am aware of, you have got to
remember that that bandwidth is going to eat into the bandwidth that you
have available for everybody else.

Those are applied on a service specific basis, not on a CLEC specific
basis. To the degree you have customers that require that, you have to
dedicate that bandwidth to them. You can\'t use it for anybody else. So
that results in an engineering issue of how much is that backbone
facility that is now coming back from that RT going to be used. What
kind of services is it going to offer. Who are the services going to be
directed to? Is it going to be a mass market kind of a service that
would not necessarily require a CVR? Or is it going to be more of a
business service that potentially would require CVR?

But all of those factors need to be considered in the engineering design
of what you finally end up with.

MR. McNAMARA: Maybe just a couple of points there. The issue of latency,
actually, CBR tends to average more latency than UBR does. So the
variation is a different issue that UBR is subject to and may have an
effect on voice over DSL.

So far as doing voice over DSL, there is nothing within platform, either
the light span platform or the DSLAM platform that would prohibit a CLEC
from doing that. It is just an incumbent ATM capability, and do whatever
you want with it.

I think I can say unequivocally at this point if Alcatel gives us
capabilities and release that you don\'t intend to use, but a CLEC would
like to use, that we\'ll make it available at cost as soon as we can
manage it.

MR. MASTERS: Wayne Masters again. Obviously, we are very pro the
solution of using a platform or a broadband service offering because it
solves the problem of colocation and universal coverage. It is very hard
to market on an RT by RT basis, our coverage anyway.

Obviously, our vendors, all of them, have great plans and are working
very hard to put a lot of service out. We are building our broadband
initiative just for ADSL. It is this first service, it is not the last
service. It is kind of the platform service. The point is, this platform
provides all of our services at this location, from POTS ‑- and again,
over half of the customers in these locations will never have broadband
needs. They will have POTS forever.

So all CBR is technically capable, and most of our vendors now are in
short time frame with various degrees of restrictions. CBR versus
universal bit rate is basically an engineering economic decision. You
can take a central office analogy. You can do the same thing ‑- why
don\'t we take a common transport trunk group between two offices and
dedicate transport to particular customers? That is called a private
line. And you can do either of those.

It is simply a case of engineering economics in doing it. We are quite
willing to consider any service. And like Bell South, we intend to roll
out many new services on these platforms. We\'ll entertain services with
anybody that can sell them on the marketplace or consumers want. And
again, our initiative here is sell DSL. Let me be real plain about that.
We want DSL sold as a choice of broadband service to the end user
consumer.

There has to be economics involved, engineering involved. I\'m not going
to activate a CBR and kill all my POTS voice service. But all of those
can be engineered out. The platforms have that flexibility going
forward. And it is just like basically straight engineering.

MR. SICKER: I wasn\'t aware that the CBR has a higher jitter. Is that
what you said?

MR. MASTERS: It has a \-- excuse me. It has a higher average latency
than UBR does.

MR. SICKER: Neil.

MR. RANSOM: Well, I\'ll address that technical thing, maybe nick another
comment. Oftentimes in the case of a continuous bit rate, if you are
transmitting information at some continuous bit rate, you are sending
out the average bit rate, which is continuous in this case. It would
take a certain amount of time to send the traffic.

If you have the full amount available to burst out, you can burst
quicker. So you know you transmit quicker, but then you might be
blocked. So for a given engineering situation, you can look at size of
queues and decide which one you would prefer to have, which one would
give you the best average delay.

Obviously, in the case of jitter, continuous bit rate has little jitter
to it.

MR. KIEDERER: That\'s right. Okay. That\'s what I wanted to clarify.

MR. RANSOM: I did want to comment, since my company was made reference
to, obviously, we\'re trying to introduce all of the various
capabilities that all of our customers are asking for, and they are
demanding all of those capabilities. Alcatel, as you know, services the
CLEC community. For instance, we sell to McCloud and Allegiance and many
other CLECs. And they are asking, as well as, quite frankly, the ILEC
customers are asking and demanding what they are demanding to all of
their suppliers for these capabilities. And our latest DSLAM, we have
said ‑- we have announced that we were providing all of the ATM service
classes, including the VDR realtime and GBR and other ‑- to use all the
alphabet soup. We are continuing to add those capabilities.

I did want to, however, address your initial question, what are the pros
and cons of this kind of architecture or approach to providing equal
access. And I thought Wayne Masters has alluded to that in noting that
as we get to the smaller sites and wanting to provide these advanced
services out of those sites, that is very difficult to do economically.
How do you justify the economics of upgrading a small site for advanced
services?

If under this architecture you combine the demands of the ILEC affiliate
as well as the various CLECs together, maybe finally you get enough
traffic demand to justify doing the upgrade to that site. If everyone
was trying to do something separate and deploy a separate DLSAM at that
point, probably no one could justify adding that capability to that
site.

So that is at least one pro argument of using the platform approach.

MR. SICKER: There is probably going to be a response to that one, I
imagine. Can I ask one thing first? Or can I also mention something?
I\'ll turn it to you, John.

The guy from Bell Atlantic ‑- I\'m sorry.

MR. KIEDERER: Charlie Kiederer.

MR. SICKER: Charles, you said that CBR wouldn\'t be likely demanded in a
consumer in a residential area? And I would be surprised to hear that
because I would think that you would want to use CBR so that you could
support other services on top of that. Is that the case, in a forward-
looking basis?

MR. KIEDERER: I\'m not saying that down the line there may not be
services that would require the use of CBR. Today, for the mass-market
deployment that we are looking at, we don\'t see the need for that.

MR. SICKER: Yeah. Competitors might have a different perspective there
because they might want to use ‑- support voice off of that.

MR. MASTERS: Let me give you another ‑- as was mentioned, you could
support voice over DSL today.

MR. SICKER: Right.

MR. MASTERS: We have done some numbers and found some numbers. If you
are doing a mass market asynchronous type offering, there are various
forms of ADSL. On an OC3, you can support somewhere between two and four
thousand customers at a 1.5 rate. If you use CBR, the numbers get down
in the 1 to 200 range. It is all a matter of ‑- it is really a matter of
the \-- and the service letter guarantees you want.

MR. SICKER: Right.

MR. MASTERS: And you can engineer to any of those. It is just a question
of economics and sizing. If the money is there and the customers are
willing to pay, we\'re in the business of selling services.

MALE SPEAKER: Could I respond to that?

MR. SICKER: I think, actually ‑- Michael?

MR. BOLTON: I was going to say I actually agree with Charles\' point
that these are engineering issues, and that\'s why we are here today
before it is built because I think what is important is to be cognizant
that there are these demands. We have already started trials in the Bay
area with streaming media on CBR. And we have to try to approximate that
demand before we put the fiber in to make sure that we have that
capacity because we think there is a robust demand.

And as to Wayne\'s point about making available all of the attributes of
the product, that is very encouraging because of the things that was in
the initial draft of the ‑- you know ‑- the proposed UNI was that you
can get, for example, one PBC. And the voiceover DSL implementations
that are being experimented with, that is a permanent virtual circuit,
require two ‑- and I think the devices that are coming out today are
capable of that kind of technology.

So being cognizant of it and being able to support it is important to
make sure that we get the maximum variety and differentiation for the
consumer products that are being offered.

MS. MIKES: We might take a step back. What I am hearing everybody say is
that it\'s the bandwidth or the service level agreement that really
matters and not the particular flavor of perhaps the line card that is
plugged in. And so could you ‑- if you agree with that or disagree with
that, let me know if that\'s an accurate assessment.

MR. BOWEN: We don\'t agree with that as the be all and end all. Let me
say it this way. Using some vendors platform \-- pick at random Alcatel
‑- using an Alcatel platform for all it can be used for is one step. And
that is a necessary step, but that\'s not sufficient, we don\'t think.
That is, that and Alcatel, I think, will eventually build HDSL-2 cards,
HDSL cards, SDSL cards, IDSL cards \-- you name it, they can build it.
Any vendor can build a card to support any kind of DSL technology.

That still puts you in a single vendor world, right? And so that\'s why
we are saying you at least have to let us be able to use a single vendor
platform for all you can use it for. But that\'s not enough. We think
you need to go beyond that and say create enough space out there so that
we can use other vendors like Copper Mountain or Paradyne or Cisco.
These other vendors have very good products. We use them right now for
our Home Run copper central office-based DSL services.

And unless there is space for other vendors\' equipment out there,
whether it is a CEV, a HUT, or a cabinet, then if you have let a single
vendor\'s solution rule the day, you have really closed the network
options down substantially, even though that vendor may be a good
vendor.

MR. KYEES: I\'d like to respond also, if I could, maybe just talk more
‑- yeah. I\'m Phil Kyees from Paradyne. Thank you. Let\'s also talk
about the customer. If there is only one service provider providing one
vendor\'s equipment, and then some other providers are reselling that
same equipment, there is not a lot of innovation, not a lot of choices
for the customer. And, yeah, we can think of the technologies that have
been developed to date. There is asymmetric, ADSL; there is symmetric,
such as G.SHDSL that is almost to its completion part as a standard.

So you have asymmetric and symmetric, but is that the limit, just those
two? Are there other things that haven\'t been developed yet? Have we
invented everything that is to be invented? Are we going to rely on one
vendor to be able to provide all of the products for customers and other
companies to resell those products, that they will provide the only ‑-
be the only source of providing new innovation?

I think there is a lot more out there that customers can get as a
choice. A lot more competition will cause the innovation.

MR. SICKER: I think, John, you probably have two points that you would
like to make.

MR. REISTER: Yeah, thanks. Thanks, Doug. I want to echo Stephen and
Phil\'s points. And for the people in the audience who are unfamiliar
with ATM, ATM essentially sets up a virtual circuit for each service
that you are offering. And there is ‑- you can set up those virtual
circuits to behave in different ways, whether they are a constant bit
rate or variable bit rate.

But a circuit implies it is a point-to-point connection between the
service provider and the customer.

So, for example, if you were doing best effort Internet access, you
would have a UVR best effort virtual circuit. If you are doing voice
over DSL, you would most likely set up a real-time variable bit rate
virtual circuit for that. If, say, the subscriber had Netmeeting or, you
know, wanted to access the Rhythms movie of the week, they would also ‑-
they would get a guaranteed service.

So you would end up with a variety of virtual circuits that you would
have. But setting up end/end virtual circuits is really just one way of
networking. And there are actually many other alternatives to that
relatively simply approach. You can actually route using IP addressing
information. You can bridge using MAC layer (phonetic) information.
Multicasting is really important in terms of, you can use IP multicast.

So, for example, one of our customers takes in a single virtual circuit
that is just a 2 megabyte video stream, and they can replicate that out
to 200 subscribers so that you don\'t have to have 200 virtual circuits
down to each one of those, down to each one of those subscribers.

So my point in going through this technical detail is that there are a
lot of alternatives. And many vendors\' equipment don\'t offer those
alternatives. And there is even new alternatives, such as multi-protocol
label-switching and so on. And I would just strongly emphasize the issue
on innovation when you have a single vendor situation. I think a lot of
venture capitalists on Sanger Road, who are backing a lot of startups
who are eager to bring some of these brand new technologies to market,
would find it very difficult to fund this innovation if it can\'t be
deployed.

MR. SICKER: I think I would like to turn it over to Jerry Stanshine now.
He has similar questions concerning the CPR. These are part of the first
series of questions. Go ahead.

MR. STANSHINE: Actually, I was just thinking in terms of a couple of
other questions. I was thinking in terms of a couple of other questions
that relate to this. As we are trying to get CBR in a variety of
services, I was wondering if anybody who wants broader cabinets could
give some suggestions on how big the cabinets should be, how much is
reasonable, how do we engineer these things.

MR. BOWEN: Well, we have ‑- Steve Bowen. We have looked at this. And as
people have said, there are cabinets of all sizes. If you take \--

MR. STANSHINE: But here is the point. Yeah, but there is a limit to how
much you should expect anybody to put in \--

MR. BOWEN: There is.

MR. STANSHINE: ‑- in anticipation maybe a CLEC will come along.

MR. BOWEN: But I would suggest that even for what I view as, you know,
an example of one of the most advanced cabinets out there, the
shrinkwrap 2016, that is ‑- we have seen pictures of this thing before.
It is basically three racks wide. And I have a hard time understanding
or agreeing with the notion that if you are going to put this on a
concrete pad out there with this little power supply and this little
battery backup, that you can\'t find space for another rack.

In other words, instead of being three racks wide, it is four racks
wide. You can build a cabinet any size you want to build it, and adding
two more feet to a cabinet configuration is not going to cause ‑- and
I\'m from California. I can tell you, the California Environmental
Quality Act and all of the things that Wayne mentioned are real. But
nobody is going to throw up a cabinet that is 2 feet wider than it is
right now. I mean, the cabinet is going to be there. And whether it\'s,
you know, 6 or 7 feet long versus 8 or 9 feet long isn\'t going to make
any real difference for cabinet placement.

The fight will come in putting the cabinet there in the first place,
right, the new cabinets.

MR. STANSHINE: But do you have anything ‑- so you would have in mind one
rack wider.

MR. BOWEN: I think you need at least one more rack. There is one rack
that ‑- well, there are two choices. Well, the front and back, you mean.

MR. STANSHINE: Yeah, front and back.

MR. BOWEN: Well, one rack wider, but front and back, yeah.

MR. STANSHINE: I mean, we are looking for a balance here.

MR. KYEES: If I could, how many CLECs could fit into one or two extra
racks? Is it one per CLEC?

MR. REISTER: Copper Mountain today has a 48 port DSLAM. It is about 5
inches high. We have a 24 port DSLAM that is about 2 inches high. So I
expect you\'ll see innovation in density over time.

MR. BOWEN: Let\'s be clear, you need ‑- it isn\'t just the DSLAM, right?
Wayne was going to say it anyway, so I\'ll say it. It isn\'t just the
DSLAM. You are going to have to have an air drop multiplexer in there.
You are going to need a fiber optic terminal in there. All these things
right now are integrate in some manufacturer\'s RTs. You need to have
that equipment in there. That equipment also can live within that kind
of footprint.

So it isn\'t just a question of, you know, 2 inch pizza box DSLAMs. You
need the supporting equipment to hand off the signal to the RBOC to
multiplex it up and go back on the fiber.

And speaking of the fiber very quickly, I don\'t think there is any real
issue, no matter what Charles says, about bandwidth. I mean, you have
got fiber going back to the office; if your OC3 can\'t handle it, guess
what you do? You make it an OC12. If that can\'t handle it, you bump it
up again. I mean, the fiber is out there right now under certain
carriers\' projects that I can\'t mention. There will be more fiber
going out there right now as well. So there will be enough fiber out
there. It is just a question of the electronics, which is economics. I
understand that. But it is possible to bump the bandwidth without limit,
basically, with today\'s technology.

MR. COOPER: Could I follow up on that? I just want to be clear. Does
that mean that the backhaul is not an issue, mixing ADSL and other kinds
of DSL?

MR. BOWEN: Absolutely. That is not an issue. I mean, right now you could
figure a network with a separate fiber curing OC3C data stream if you
want to, but you don\'t have to because right now interoffice transport,
you have got, you know, signals of all kinds, regular old circuit switch
traffic, ATM traffic, frame traffic. You name it, it goes across the
same fibers. There aren\'t separate fibers right now interoffice for
separate kinds of technology really.

MR. STANSHINE: Okay. I\'m not necessarily looking for detailed entries
at this point.

But, you know, we are looking for an idea of how much bigger does seem
reasonable, do you need an add/drop box, do you need additional power,
how much? Just get an idea of what it takes to make an effective \--

MR. BOWEN: All of the equipment needs power. And Neil was right
about \-- we agree with that, that is that when you add more equipment
‑- for example, right now, the Alcatel 2016 ‑-

MR. STANSHINE: Because I take seriously ‑- excuse me ‑- the question
raised, yeah, you can make it infinitely big, and it costs infinitely
much. So we are looking at making it a little bigger and do some good.

MR. BOWEN: A little bigger is enough.

MR. STANSHINE: Okay.

MR. BOWEN: That is, you have got to support it with power, you have got
to support it with battery backup. We agree with that. As a matter of
fact, right now you couldn\'t configure the Alcatel 2016 with ADSL cards
because there would be ‑- it couldn\'t handle the heat dissipation. If
you put all the cards in there as new or used cards, it couldn\'t handle
it. But that will get better. Right, Neil? That will get better.

(Laughter)

MR. BOWEN: My point is that I\'m not trying to belittle and say all we
need is a pizza box DSLAM. We need to have a slightly larger cabinet. We
need to have power support, battery backup like everybody else does for
that equipment.

MR. STANSHINE: Even if you are in the cabinet, you need to get the
copper?

MR. BOWEN: Yes.

MR. STANSHINE: I don\'t how the copper is \--

MR. BOWEN: You need to get to that. And you can do that when you bring a
feeder cable in, as more architecture as it. Instead of putting all of
the pairs from that feeder cable into the back pl

ane of the DLC, you peel off 100 pairs and you put over onto this ‑- to
this rack over here for somebody else\'s use. That\'s a very simple
thing to do.

The copper is just a big fat cable in a sheath, and you can pull pairs
off as you choose as you install it. So we re saying, you know, a little
bit bigger cabinet, sufficient power, sufficient supporting equipment so
we can hand a DS3 or an OC signal back to the RBOC for transport.

MS. MANCHESTER: This is Linda Manchester from Lucent Technologies. I
would just like to make a couple of comments. The first is I would like
to first go on record of saying that I think that there is a good reason
to have a platform that is shared for both narrow-band and broadband
services in order to get economies in scale and to be able to get
deployment quicker to the popopulation.

There is also a savings there because you get to share management
systems, powering. You get to share all of the interfaces and the common
infrastructure of the cabinet.

MR. STANSHINE: Okay. So you are talking about a ‑- I guess to
understand, you are talking about a common cabinet. You are not
necessarily talking about a common system in the cabinet?

MS. MANCHESTER: No. I\'m actually talking ‑- in this particular case, I
am talking about both, a common cabinet, and within that cabinet, there
are very positive reasons to have an integrated solution, of which case
you would wholesale, you know, like technology out of that and be able
to provide services.

The pros on that has to do with the economies of scale, sharing of
commons, as well as getting deployment there quicker once you have the
platform in place. There is also a need in some cases to have the
ability to collocate. And I think we have heard that there are offerings
to put colocation space. The two reasons to collocate, I would say,
would be 1) because you want to provide innovative technology that
isn\'t readily present yet on the platforms of choice. And there is
something there, a smaller entity that you want to put out there.

Now that would say that if you are going to put multiple of those in,
you are talking about small deployment rates, and you are talking about
now where you cannot necessarily share all of the infrastructure
appropriately in that cabinet. So you do have the additional space of
the power or the cabling. But the thing that we are also missing here is
there is a complete management scheme that you have within that common
cabinet. And there is a management of what do you do with the battery
backup and all of the powering of if power goes off and how do you treat
each and every one of the systems.

Today, in a single cabinet, it is treated as a unit, not as separate
entities. So that is a very complex management issue in those cases that
would need to be addressed.

The second reason to have co-location could perhaps be that you have
such a take rate of what you want that it actually is economical as a
competitive LEC to come in and own your own facilities and own it at a
scale that is reasonable and is economical for you. Now at that point, I
think you need to look at, based on what we heard about spaces and how
much space there is for colocation, now that I think takes you out of
the common cabinet approach.

So, Jerry, you are looking at me  \--

MR. STANSHINE: The last sentence, could you back up ‑-

MS. MANCHESTER: The last sentence is there is two reasons for
colocation. The second reason, being the last sentence, is that you want
actually a greater take rate, that you need a larger system and not
necessarily the pizza box space systems that John had talked about.

In that case, I think that we have now moved out of the space of being
able to be collocated within a cabinet. Maybe in a CEV or HUT, but not
in a cabinet. And I think we have to take that into consideration, too,
because there is a difference. If it is a single technology and it is
low take rate, one has to also look at are you utilizing that free space
within the cabinet appropriately for an entire system, from power
through management, in order to be able to bring only a couple of lines
of that technology to the market.

MR. BOLTON: Jerry, this is Gary Bolton from Catena Networks. I just
wanted to follow up on Linda\'s comments. And I think, you know, if we
look at the ultimate focus here is to provide advanced services to all
Americans. And, basically, if you look at the subscriber ‑- and the way
to do that is to make broadband access ubiquitous, as ubiquitous, say,
as POTS network is.

So today, if you look at the POTS network, you know, there is 175
million telephone lines out there, so it is very available and it is
very affordable. And if we are going to get broadband access available
to all Americans and make it that level of affordability, we have to
drive the economics and make it very economically viable to provide that
service.

I don\'t think anybody on the panel would disagree the most
cost-effective way to do that is through integration. And as we start
pushing fiber and fiber deeper and closer to subscribers, the number of
subscribers that we are amortizing, the back-hall facilities become
smaller and smaller. So it becomes very difficult for service providers
to have viable business cases to go out and put all kinds of overlay
equipment out there.

So I think if you look at it from a perspective of the choice of pairs
in place, and how do you manage that spectrum of the choice of pairs ‑-
so if you have, you know. 1.1 megahertz of spectrum to work with, you
know, you really to be able to take that and be able to manage services
on that loop and to provide a single point of access to be able to
terminate that loop and provide both, you know, your POTS, say, and
broadband access at the most cost-effective means, and then be able to
share those facilities.

Since I think that\'s what, you know, Linda was talking about having a
product and the service offering, that it is all integrated into one
point of access.

And this one further point to that is, I think we have to be very
careful as we are looking at this moment in time, that if we start
looking out the next couple of years, if we start putting things like
mechanical POTS footers as regulatory demarks between services, then we
start to strand bandwidth. And I think that we can\'t afford to ‑- you
know, while in the past, 4 megahertz ‑- or, excuse me, 4 kilohertz,
seemed like a lot of bandwidth for POTS, and then 56 kilobytes seems
like a lot for a modem, now we are talking about having enough spectrum
to provide DSL.

Well, by putting the POTS footer in, you lose 27 kilohertz of prime
bandwidth, and you strand both the base band of the F part of the
spectrum to the DSL part of the spectrum.

So with all of the technology innovation going on and the amount of
money being poured in by Silicon Valley, you have to be very careful not
to do that and to be able to provide the widest range of options to be
able to provide services over the loop.

So I guess in summary, if you look at POTS as a volume service today in
the way we deploy POTS, and it is ubiquitous, I think we have to use
that same model to deploy broadband and to make sure that we deploy
broadband in a way that it is a volume service. So don\'t look at it
trying to say how can we deploy like a niche service, you know, to make
cabinets a little bit bigger or do something a little bit different to
be able to do, you know, here and there, but look at it from a holistic
perspective of how do you make the most cost effective to all Americans.

MR. STANSHINE: Okay. I am going to ‑- the way I hear the summary of the
two arguments at this stage, a relatively modest ‑- somebody shows a
relatively modest cost. An increase in the size of the cabinet would
allow the CLECs to put their own equipment there conceivably. But it
nonetheless is not the most efficient way to spend your resources.

MR. KIEDERER: One other comment to that.

MALE SPEAKER: I\'d like to add that, too, when he is done.

(Laughter)

MR. KIEDERER: You know, yeah, perhaps it is not the most efficient way.
But I think we also need to think about, you know, how do ‑-
logistically, how do you really handle something like that? I mean, the
suggestion was made, yeah, you can add one more shelf.

If you can put in three, three bays, you can put in four bays. Yeah, and
that is probably true. But who is going to deal with the issues ‑- and
it is usually going to come down to the incumbent LECs ‑- of all of the
right of way of the zoning issues of dealing with the local
municipalities, of some of the implications that Wayne mentioned earlier
about the fact that you are limited in many municipalities to what you
can put in terms of size.

So it is not just simple to say you can add another bay. And is one bay
enough? I mean, how many CLECs is going to come into a particular
location? Is one bay enough to cover two competitive local exchange
cabinets? What happens when the third one comes in?

The comment was made that, you know, the RTs are becoming the COs of the
future. Well, they are not central offices. In no way, shape, or form
are they central offices. They are not hundreds or 200,000 square feet,
you know. We are talking about 60 square feet of space that we are
dealing with.

And then the one thing that was mentioned here about efficiencies, you
know, what happens as you start deploying equipment in there, and that
space, which typically today is used very efficiently, all of a sudden
becomes a nonefficient use of space because you do have multiple
providers within that particular location.

And then the one topic that hasn\'t been done yet because this is a
technical type of forum, but on all of these issues that we are talking
about, there is always an operations and systems implication that needs
to be addressed. And those typically become the black hole. Not the
technical part of it, but it is the operations and systems.

MR. MASTERS: A follow-up. We talked about ‑- because we looked hard at
this. If I could have solved a problem by putting 2 square feet more of
cabinet somewhere, if I could ‑- the embedded base was a killer. If you
are trying to market in a ‑- most RTs feet around large ones, 800 homes.
That is the largest. Then it goes down to four to eight homes.

So you get into how can I ‑‑ who am I to make the rule that there is
going to be one, two, three, or four CLECs in these.

MR. OLSEN: I thought that the earlier announcement from SBC was going to
be 20 million loops on 20,000 RTs, which would suggest an average of
about 1,000 per RT, which is larger than what you were describing ‑-

MR. MASTERS: Yes, but there is a piece of our project is that those
loops in the L zone, they cannot be served by DSL for various reasons.
You are actually then taking customers working between 12,000 and 17,000
feet today, and you are given the ability to recon them to a RT. So
there is more RTs in that homes.

It works out between the larger 800 to 1,000. But a new one going in
historically is around 800. It can vary all over the map. That\'s the
large end. Then it goes so much smaller.

OSS and systems is a big one. We talk about putting a piece of copper in
there and crossconnecting it. That is a miniframe. All these eats space
up very quickly. We had studies done. We could find no way with the
extra bay to put more than one, possibly two in. We just didn\'t think
this solved the problem.

Then you get into all of the OSSs from alarming, maintenance,
provisioning, testing, all of those things that fall on there. We just
came back with that the universal platform was a much more economical
way to get the mass- market format and do it now, and not wait until all
boxes were redesigned or redone because I\'d ask you how long it would
take to redesign a 2016 cabinet to provide another rack space, and
you\'ll give me more than a day, just timewise.

MR. REISTER: The systems issue applies to whether it is an integrated
platform, though, which is going to be management alarm provisioning, or
if you have separate units. So the systems issue, I think, is similar.
And I just would quickly counter, we do have customers applying 24-port
DSLAMs in buildings, and they put it in the basement of the building.
And they can make the economics work.

MR. KIEDERER: It is a lot cheaper to do it in the basement of buildings
than in the outside plant.

MR. SICKER: Could we move off the space issue?

MR. McNAMARA: Just one small ‑-

MR. SICKER: Okay.

MR. McNAMARA: Forget about moderate cost. This is not at all moderate
cost. If you talk about taking a cabinet like a 2016 and adding an
additional bay on it, I can assure you that the cost of the sheet metal,
the additional pad, the rectifiers, the battery, probably about \$10,000
for that additional rack.

MR. REISTER: Okay. Jerry?

MR. STANSHINE: Actually, I was going to get into the CBR stuff that Doug
said I was going to get into when we started. We are looking at the
bottom of page 1. There is a collection of three questions there about
CBR. And there is also a question about operations in support of CBR,
which is the next to last question of that series under item 1. And I
wanted to get into those.

I\'ll start with Neil, Dr. Ransom, at Alcatel. Can you offer CBR virtual
path, virtual circuits for various parties that want it with your
system, and is this useful, valuable, important for the CLECs? We\'ll
get into managing it by the ILECs.

MR. RANSOM: Well, in a sense, I need a clarification on the question.

MR. STANSHINE: Sure.

MR. RANSOM: A CBR between what and what? Between a given customer\'s
interface on ‑- for instance, an integrated ADSL and a digital carrier,
can you offer that individual customer a CBR service. And if that is the
question, then the answer is yes. In fact, our particular product, both
in our stand-alone DSLAM and in the integrated light-span product can
support CBR.

If you are talking about a CLEC providing collocated equipment and
getting CBR out of it, then what that implies somehow to me, to use more
‑- that\'s not what you mean.

MR. STANSHINE: I was now talking more in the integrated platform
approach.

MR. RANSOM: In the integrated platform, currently we can offer CBR to
individual customers. I also understood \--

MR. STANSHINE: I\'m sorry. This will be a virtual circuit as a virtual
‑- it is a virtual circuit.

MR. RANSOM: A virtual circuit in the CBR.

MR. STANSHINE: Yeah.

MR. RANSOM: Yes. In the current case in a permanent virtual circuit, CBR
service to a given customer.

MR. ROSENSTEIN: Dave Rosenstein from Covad. A couple of things, I guess,
I would like to bring up on the issue of CBR. First of all, it is a ‑-
the way that we are looking at it initially would be CBR is not a very
flexible method. But compared to UBR, CBR is the easiest way to give
individual CLECs some control over their own destiny.

MR. STANSHINE: Feel free to mention \--

MR. ROSENSTEIN: Well, okay. And those are all valid pieces. I kind of
wanted to just focus on the CBR issue for a moment. One of the options
that had been proposed would be to offer the CLECs a CBR virtual path
between the Alcatel trunk and the piece of CO equipment sometimes called
the OCD, and basically allow the CLECs to purchase one or more CBR
paths, which to take multiple circuits, multiple end user circuits, and
put them in.

What that would let the CLEC do is control over-subscription by service.
So, for instance, I can buy a trunk of bandwidth, and let\'s just pick a
number and say ten bag, and I can oversubscribe that by whatever factor
I choose.

If I want to do a voice service there ‑-

MR. STANSHINE: This would be from the DSLAM through whatever common ATM
switch that an ILEC might have?

MR. ROSENSTEIN: Correct.

MR. STANSHINE: Right into the CLEC\'s port?

MR. ROSENSTEIN: Correct, correct. And basically, what the option here
would be, that a CLEC can make an economic error \-- not an economic
error, an economic decision. I agree, it is an economic decision. I
think it is our economic decision to say, well, I would like to buy this
bandwidth and oversubscribe it one to one, ten to one, 100 to one, based
on the type of service I am offering and the type of end user or the
type of application that I am providing on that service.

MR. RANSOM: Well, if I might respond because I thought perhaps it was in
that context that it had been brought up. And first off, whether or not
the current product that Alcatel provides can take a CBR and then let
that be shared, a CBR class virtual path, and then share that over some
subgroup of customers so that you can vary the concentration rate and
therefore a special class of service to that subset.

I\'m afraid to say that we don\'t do that right now, but it sounds very
interesting. It certainly doesn\'t violate any speed of light. It is
certainly something that could be implemented and potentially could be
very attractive, not just for CLECs, but for ILECs themselves who would
like to offer various classes of services, platinum level and gold level
services to their customer. It may be very attractive.

MR. ROSENSTEIN: Thanks. Just to add in, that\'s a ‑- I think that is a
reasonable first step to this broadband UNI portion of the discussion.

MR. STANSHINE: Do you know of any RT manufacturers that offer that kind
of \--

MR. ROSENSTEIN: Not offhand, I don\'t. It is an unusual application. But
then again, that\'s why we are all here, right? This is an unusual
scenario. It would be ‑- you know, the endgame, I think, would be to
provide the true ATM traffic management forum for O specification
classes of service, which do let you control things like cell delay
revolution and to control jittering loss and all of the shaping
functions that really truly you would want on a per virtual circuit
basis. However, I think that may be two steps down the road.

MR. STANSHINE: Okay. So you are really interested in the virtual path
approach, basically a trunk for the CLEC rather than getting a PVC
approach on each individual end customer.

MR. ROSENSTEIN: I\'m really interested in getting ADSL access wherever
the ILEC currently has ADSL access. And if the virtual path approach is
the way that the vendors can more quickly provide us a reasonable
solution, then I think that that would be a reasonable first step. It
does give us some degree of differentiation. You know, there are a few
other things, I think, that are critical for differentiation here and
not \--

(Simultaneous discussion)

MR. STANSHINE: ‑- the virtual path approach does.

MR. ROSENSTEIN: Virtual path over pure UBR.

(Simultaneous discussion)

MR. STANSHINE: The virtual circuit approach is not \--

MR. ROSENSTEIN: The virtual circuit approach actually has a lot of
benefits that are even better. You still are operating in an environment
now where you are competing with other types of traffic from other
vendors that you don\'t necessarily control. But to the degree that it
lets you control many more ‑- if they were to support all of the traffic
management classes and all of the features that go with them, that would
be useful. But virtual path does the job for now.

MR. REISTER: Yeah. I\'d like to contribute to this. I think to augment
your point, CBR is a very good idea as a virtual path because ‑- think
of it like a T1 or a DS3, that you have got ‑- the CLEC now has that
guaranteed chunk of bandwidth. And with CBR, no other service can
interfere with that.

MR. STANSHINE: Again, you are talking virtual \--

MR. REISTER: So the point is it is just like when a CLEC is in a central
office and buys a DS3, and they can put several hundred customers\'
virtual circuits inside of it. But doing CBR on a per customer basis
would be bordering on stupid because then you have to permanently
allocate bandwidth per customer, per service per customer.

So if a customer has five services, you would have to allocate however
much to them, and you would get no statistical benefits between your
subscribers, which would be awful in the outside plant in the RT
environment.

MR. ROSENSTEIN: I just was going to say you are doing CBR per customer.
It would be basically turning your ATM network into a TDM network and
undoing all of the benefits.

MR. REISTER: Right.

MR. STANSHINE: But you really need both. That is, if vendors right now
can support PVCs of various flavors, we need that, not just UBR. We
would also like to have permanent virtual paths at CBR so that we can do
our own ‑-

MR. OLSEN: One important point, as we have been talking about colocation
and then the platform and then maintaining loop plan, we have had broad
general agreement. On this topic, we are likening a CBR path to what is
essentially interoffice transport, the RT as serving as the central
office. To date, only one of the incumbents has committed to make that
available on prices. And that is very important because that is probably
the single greatest factor in the economics of competitive DSL, is that
transport from the RT to the COF and the CO to CO.

So as we talk about it, we should be mindful that that hasn\'t reached
broad consensus. Maybe it has, it just hasn\'t been articulated. But it
is an important issue.

MR. REISTER: By the way, John, you mentioned this in the context of the
integrated box. I think the CBR virtual path is critical with having a
pizza box for a CLEC and then enable us to, you know, take out an OC3 or
DS3 or whatever the defined interface is, stick it into the Alcatel RT,
and then be able to say if it is an OC3, fine, you can have, you know,
20 meg or however many meg CBR, and you can stick all of your customers
within that.

MR. RANSOM: That was in fact the third type that I thought perhaps you
might have been referring to. And that\'s where there is a separate
collocated piece of equipment they want, which I can only describe as a
UNI interface, to keep our abbreviations going here. If you offer an ATM
UNI, somehow drop at an RT site, then potentially something could
connect to it and be given some ‑- well, various classes of service, and
certainly CBR.

I would say right now we have not seen much demand for UNI interfaces
directly out of a remote terminal. But that is obviously a capability
that might be done perhaps at the DS3 rate or \--

MR. REISTER: And you are referring to UNI, right, \"user network
interface\"?

MR. RANSOM: Yes.

MR. REISTER: Not UNI, unbundled \--

MR. RANSOM: Of course, I would never mention that one.

(Laughter)

MR. BOWEN: We can also do this via signup channels, too. Some of the
derivation of bandwidth doesn\'t need to be, you know, ATM based. It can
just be a straight sign-up channel as well.

MALE SPEAKER: That would just make that a little more expensive.

MR. STANSHINE: I hear what you are talking about ‑- now if I understand
it right, is the main system box, whether Alcatel\'s or somebody else,
now has an add-drop multiplexer that not only handled their RT, it took
interfaces from other vendors\' equipment, and it did ATM multiplexing
before it did time division multiplexing.

MR. REISTER: And the add/drop multiplexing point is you are adding some
complexity to it in that add/drop multiplexing is really a TDM function.
But the idea was you can take an OC3 out of a pizza box, plug it into ‑-
I\'m sorry I don\'t know the model number ‑- the Alcatel product, and
that OC3 would go in, but the CLEC wouldn\'t necessarily have to get 155
megabits. You could have a, you know, a 10 megabit, whatever the CLEC
orders as a CBR virtual path, and then you could put all of your
services inside of that.

So it is not a true ‑- it is definitely not an add/drop multiplexing
function.

MR. STANSHINE: You make the DSLAM part of this. You don\'t make the ADM
part or anything like that.

MR. REISTER: Well, it is more of an ATM switching function than an
add/drop multiplexing function in that you are taking ‑- you have the
OC3 from the pizza box into the ILEC product, and the ILEC product would
basically pull a permanent virtual path off of that OC3 using ATM
technology as opposed to using sonnet (phonetic) PDM time slotting into
that sonnet transport.

MR. STANSHINE: Mr. Nokia, the cord is blocking part of your last name,
Bill something.

MR. BUCK: This is Bill Buck from Nokia. And we have exactly that, what
we are talking about here is where you can set up a ‑- it is a
statistical multiplexer, basically ATM statistical multiplexer, where
you have either, say, an OC3 or DS3 UNI in our case that we offer that
could support a second device.

MR. GETCHELL: Wayne Getchell from Nortel. Essentially, what I am hearing
from you folks is something that we have been considering now for a
while, and that\'s the ability to share equipment by defining a service
level agreement between the end subscriber and the RT, and then another
one from the RT back to the CO. They could be one and the same, or they
could be independent. But if you define specific attributes of that
service level agreement, then you can define an envelope that allows you
to deliver any advanced service you wish, so that envelope could contain
things like guarantees of availability, bandwidth, packet delay, and you
can define a variety of these for a variety of different potential
applications.

One can also perceive of being able to provide several classes of
service with each one of these SLAs. I know that we will offer on VCs or
PVCs, SPCs, or VPs either UBR, UBR-plus, VBR, VBR NT, a whole variety of
capabilities, as well as straight IP. So it opens up the opportunity for
the competitors to go in and innovate. It also provides an envelope with
which the incumbents can operate.

That kind of sharing also enables the incumbents to retain ownership of
the equipment so that they can do fault isolation and restoration as
quickly as possible. And in addition to that, it does require, however,
that you take a slightly different approach as well to the OANM \-- that
we really haven\'t mentioned here to any extent so that both the
competitor and the incumbent have views, albeit different, with
different capabilities and priorities to make changes.

MR. KIEDERER: If I just may add one final comment, it has been very
interesting listening to all of the vendors and what they think they can
do, and they can do a lot. They have a lot of talented expertise. But I
think in terms of a reality check, we need to keep in mind that, you
know, certainly if we ask them to do something, they\'ll do it. But we
have got to consider there is a cost element to do that and there is a
time frame element to do that, and that when it then becomes available,
we need also then have to integrate it technically into the network and
operationally, administratively into the network as well.

And in the meantime, you know, what are we doing in terms of the
potential delay of these types of services to the mass market? What is
happening out there with another form of competition that is trying to
do the same thing, where we are all waiting for these things to happen?
So I think we just need to keep that in mind.

MR. SICKER: We have really focused on the platform, not very ‑- not at
really a deep level. We have focused much more on colocation. And I was
wondering if there was anything more within the notion of a platform
that anyone wanted to bring up before we move on to adjacent
colocations.

MR. OLSEN: I guess I would respond briefly to Charles\' point, is that
we can be optimistic about those kinds of ‑- one is, as Lou said, we
want to exploit the opportunities in the equipment, and it appears that
there is quite a few. And our concern has been those shouldn\'t be
hobbled by the way that it is offered. But concerns about operational
feasibility have always been daunting.

For example, as I recall in the line-sharing discussions, SBC said it
could take two years. But I think SBC is now on the record ‑- says it
will be ready in May, which is just a few scant months. So the ability
to overcome these have been pretty impressive. And I think that we can
expect that as we discuss these policies \--

MR. STANSHINE: You think we can split on a piece of equipment \--

MR. OLSEN: That\'s right. But originally, we said it was going to be a
couple of years, and we\'re doing much better. I think that we can
overcome these things. And certainly to the extent that there is
customer and CLEC demand for them, we can find a way to accommodate them
on a reasonable ‑- you know, through industry fora, et cetera, that
accommodates both the concerns about rapid implementation and costs.

MR. KIEDERER: Not to get into a debate with my esteemed colleague there,
but there is readiness and there is readiness. And while we will be able
to offer, as SBC will, line sharing, you know, by June 6th, it by no
means will be a simple task operationally. Just in terms of the
availability of some of the systems from our major supplier and supports
are embedded, our operational systems ‑- because the software releases
will not be available until the end of the year.

So we are going to be doing a lot of things on a manual basis.

MR. BOWEN: Could I just have one last point on this issue? The reality
is that the planning cycles for these kinds of major upgrades are long.
SBC began this, I believe, back in 1998. You know, DSE got bought by
Neil\'s company in January or so of last year, whenever it was. The
rollout of project ProlTel (phonetic) takes a long time. And I guess
I\'m a little bit disturbed to hear Charles and Wayne and so forth say,
well, this ‑- you know, we are not ready for this other choice when, you
know, we\'re your best customers here. That is, we want to use the
technology. But you never asked us what we wanted, you know.

You need to get us in the development cycle so we can say, gee, we would
like to have a separate rack, or gee, we would like to be able to do all
of these flavors on a single vendor platform. But you have got to ‑- you
know, you have got to ask us before we can tell you what we need.

So, you know, here we are now telling you we want to do more than you
thought we wanted you to do. And if that involves some delay in the
cycles, then so be it for a fair market. And we prefer technical
solutions, but we are telling you that we think we need more than maybe
you thought we did. And now is the time for you to understand that and
then move forward.

MR. ROSENSTEIN: I just wanted to add one piece to that, if it is okay.
Sorry. One thing to say, if you add some delay, so be it. I would say
that I don\'t necessarily completely agree with that inasmuch as there
are already ADSL deployments happening out of remotes. And, you know, I
think that if we delay \-- you know, there is a landgrab in progress.
And if we delay for the perfect solution, if we don\'t start until we
have the perfect solution, we may never start.

As CLECs, I think that we have to agree to start somewhere, and then,
you know, make it part of the deal that we work forward to these more
complete solutions, including the full ‑- all of the other areas of
invasion that CLECs really require to do a different service, to have a
service that a consumer would choose and push everybody\'s technology
forward.

MR. STANSHINE: Okay. One thing that I haven\'t heard contradicted \-- I
wanted to make sure I understood \-- is, we are talking an arrangement
where you could have several DSLAMs in a rack. But to connect them and
use fiber that is already there being used by an incumbent officially,
they would have to connect to an ATM switch to do statistical multiplex.
It would then have to have an interface with an add/drop box to get
towards the fiber.

Is that basically an accurate picture of what would be needed here?

MR. BOWEN: It depends on whether you go with really TDO approach, you
know, sign-up channels, or if you do what John was talking about, which
is, you know, use existing ATM approach and avoid the actual add/drop
multiplexer.

MR. REISTER: I mean, RTs have the ability to send T1s out on this driver
side, I believe. You could just plug in, you know, clod T1 with IMA. The
same concept applies to making a handful of OC3 interfaces available and
then having an ATM switch behind those. So you ‑- I mean, that\'s really
‑- it\'s an ATM concentration function, and ATM concentration functions
are ‑- you can get them on chip today.

MR. STANSHINE: It does have to be mountable on a board, but yes. Okay.

MR. MASTERS: I\'d like to say something. There is a lot of creativity. A
lot of these things can be done and will be done through time. I hear
the word delay. That is not a word I can use. We have an insatiable
appetite out there for customers. If we don\'t provide a service to
them, they will find somebody else. They are not going to wait for a
perfect solution.

There is a way you can roll out the technology you have today and the
service you have today, continue building new capability in as rapidly
as possible. Vendors like to talk about what is possible versus what is
shippable in what is in place today. And all of this has to be
integrated in. The period is becoming more rapid and has to become more
rapid. But none of us are going to agree to a delay and wait until the
perfect Utopia shows up.

You also have to keep in mind the embedded base. You talked a lot about
what can be done in new cabinets. And that\'s all true. But you have
cabinets there with limited fiber and limited space that represent
customers also that want services. But you have to find a blend of both.

We\'re willing to work with any form on that, any set of industries on
that. But it has got to be in the conditions that we deploy services as
rapidly as we can.

MR. SICKER: Okay. Thank you. As tempting as it is to maybe launch into
line sharing and remote terminals, I would like to put that off maybe
until the end of the meeting today.

I would like to now talk about the third series of questions. And this
focuses on adjacent colocation. For the audience, this is the notion of
having a slab where you have an RT, the ILEC\'s RT, and a competitor
coming in and placing something next to it.

And the first question, I guess, is an interesting one. I would like to
know are there any proposals by the competitive LECs to build colocation
hotels on remote terminals? Has there been any?

MR. BOWEN: I\'ll take that. This is not an attractive solution, for a
couple of reasons.

MR. SICKER: We\'ll get to that. So no one is doing that? Is that
correct?

MR. OLSEN: We\'re not doing it.

MR. SICKER: Go ahead.

MR. BOWEN: Okay. All the problems that Wayne identified, especially in
California, about doing the cities and towns, you can just double or
triple those if you want to talk about us going out and pouring our own
slab and plopping our own RT down on that slab.

I mean, you know, it gets exponentially more difficult, first of all, in
major jurisdictions. Second of all, it simply, I don\'t think is
economic to do that, that is, although I don\'t agree fully with the
statements that ‑- you can only prove in an RT if you had everybody\'s
demand included in the calculus, in part because SBC has said these
prove in on cost savings alone, stand-alone.

But it is true that for us to go out and put in next to our ORTs for the
level of demand that, say, Rhythms is going to have, which, of course,
is higher than North Points or Covad, but even so ‑-

(Laughter)

MR. BOWEN: The level of demand an individual CLEC has for a serving area
that is maybe maximum 2,000, more like a 1,000 or 800 or so forth, and
the take rates you are talking about \-- I don\'t think those kinds of
things prove in on a separate, you know, CLEC-owned adjacent colocation
kind of paradigm.

MR. SICKER: Do most of the other competitors agree with that at this
point? Johanna Mikes.

MS. MIKES: I just wanted to take a step back in terms of the adjacent
colocation issues and ask step-by-step approach, what would be involved,
what would a CLEC or a separate affiliate of an incumbent encounter in
terms of adjacent colocation?

MR. BOWEN: Okay. What you would have to do is go out and do the usual
permitting things with the city or the jurisdiction to be able to do it
in the first place. Then it depends. That is, it depends on how
cooperative the ILEC wants to be in taking handoffs and giving handoffs
of the cabling.

For example, in SBC serving configuration, they will have an average of
20 RTs per central office. Each of those serves an average of four SAIs.
Now the SAIs are fed by copper. That is, fiber doesn\'t go out to the
SAIs, copper does. And so you get the question of how do you pick up the
subscriber-side interface. How do you get the copper, you know, coming
in from the houses to your RTs so you can DSLAM it.

Now what we have been offered so far ‑- I mean, technically, you need to
get out there somehow. What we have been offered is you can bring your
cable to our SAIs. That is pretty unattractive from an economic
standpoint, I can tell you. You can probably imagine why.

If we could take a handoff of a portion of a feeder cable, for example,
100 pairs or whatever, broken away before it goes into the back plane of
their cabinet equipment, that could be brought across underground
through a little conduit to come up underneath our RT. Then we would
have to hand back to them ‑- well, that\'s how you get to the copper,
okay?

You also have to get back to the network somehow. And you have to get ‑-
you know, coming out of the back of your DSLAM, you\'ll have either DS3
or OC level signal, which is going to ride, you hope, fiber back to
someplace.

Now I guess one option ‑- we have been offered this option as well by
Bell Atlantic \-- is you can go ahead and deploy your own fiber out to
those RTs, knock yourself out. Not very attractive, not very attractive
economically.

We would like to ride their fiber back. And Charles is agreeing with me
now \-- you are going to let us do that, right? \-- you would like to
ride the existing fiber back from these RTs to the central offices. And
so we have to give an handoff, DS3 or OC-level handoff, back to the ILEC
at their RT, and they have to be able to accept that somehow, whether it
is, you know, the ATM solution or the separate TDM sonnet channel kind
of solution.

We have got to be able to hand them back, in effect, a \"fat pipe\" that
goes back to the central office. They hand that back to us in our
colocation space in the central office.

So basically, it is placement of the pad and the equipment. And, of
course, you need the same kind of backup power, both AC and backup
power, that you get with their RTs. You have to do that yourself. And
then you have the connectivity issues, you know, getting to the fiber,
getting to the copper. And then you have got all of the zoning issues
and first acquisition.

So you are replicating everything that they have to do. And I can tell
you, the cities and towns know them and like them better than they know
and like us. They\'ll say Rhythms who? And they know who Pac Bell is.
They know who Bell Atlantic is. So it is a much more difficult job just
with the same statutory rights to build things.

So that is what is involved if we build an adjacent RT, if you will.

MR. KIEDERER: Just to clarify the record here a bit on a statement that
Steve made.

(Laughter)

MR. KIEDERER: While it is true that the CLECs certainly can deploy their
own fiber if they choose to do so, they also have that option, we at
Bell Atlantic certainly intend to meet the obligations under the union
remand and provide dark fiber and the loop from that location, to the
degree it exists and is technically feasible to do so.

MR. BOWEN: We want to direct the lid stuff though.

MR. MASTERS: Yeah. And I hate to harp on existing, but you may or may
not have five in those. The existing is existing, what it was when it
was built. In existing locations, adjacent structure may be the only
answer in some places. That is not attractive. We don\'t like it either
because, you know, even if it is Rhythms, they say it is the telephone
company. I don\'t care who it is, we catch the grief.

We are all pushing hard to find a way to live within existing space
because space is so hard to get out there. That\'s the bottom line.

MR. McNAMARA: Some of the things Steve is alluding to regarding the
interconnection problems with separate cabinets are actually the same
whether it is separate cabinets or a common cabinet. Accessing a
distribution facility is a bear no matter how you do it.

The cost, obviously, for stand-alone cabinet are somewhat higher than
trying to expand an existing cabinet. And again, we are talking about
new options only. If it is an existing cabinet, you don\'t have any
choice but to place a separate cabinet.

MR. SICKER: Would anyone else like to add to that?

MR. REISTER: I would just say ‑- I\'m sorry. The key to making this
competitive is in the economics. And it is really the fixed costs that
contribute to the RT really being a natural monopoly in the economic
sense. And if you look at the components of fixed costs, it is the
permitting, the general contractor, the civil engineer, the zoning, all
of the things you have to do there that have absolutely nothing to do
with telecommunications. It has to do with constructing on a sidewalk
somewhere. That is actually a pretty high fixed costs.

You have the costs of the equipment, which while it is a fixed cost, it
does vary with the number of lines you are trying to support. So I
alluded earlier to the comment that you can create a pizza box and cost
effectively serve in a multitenant building ‑- we have customers doing
this today ‑- with the equipment. And Charles did note that it is more
expensive deploying out in the field. I think a lot of that is because
of that first concrete and bricks and sheet metal fixed costs. So you
can create a lower fixed cost, smaller unit.

And then there is really a fixed cost, plugging it into the backbone,
which is that fiber crossconnect that you have got to do before you can
offer any service, whether it is fiber or end by DS1 or DS3. And then
you have variable costs, which really don\'t get into the natural
monopoly aspects of it economically, the variable costs being you need
to plug in the copper as you are getting customers. And everybody needs
to do that.

MR. REEL: Well, I would just like to ask the ILECs what about your
affiliates. Are they going to have to collocate adjacent to some of the
equipment that is already filled out?

MR. MASTERS: I guess I\'m the only that has an affiliate today. If they
decide to deploy a Copper Mountain solution ‑- and believe it or not,
they like the product ‑- for your customer, they would have to, unless
they use the platform.

You know, obviously, we are trying to encourage and make the platform as
robust as we can as a service to meet as many needs as we can. If it
doesn\'t meet those needs, and there will be occasions or niches of
those things, then you have to do colocation.

There is a good chance a lot of those locations will fall under CEVs and
HUTs, though. If you look at the ‑- most of those are business-related
services or off-rand scale ‑- of course, there are homes in California
that have DS3s, too. I mean, business and consumers, it is hard to get a
mix of any more.

It will probably fall, in our territory at least, pretty well into CEVs
and HUTs. So I think there is a lot of colocation opportunity there that
will take care of a lot of this. When you get to the a cabinet, though,
if you have an embedded base and it is existing and it is locked in, you
have to go adjacent. There is just absolutely no choice. If it is new,
then you look at what space is available there, unless there is some
space available inside of it.

That\'s why we work so hard to get a universal service platform that can
accommodate all of those needs. It is the same reason in years past you
didn\'t put several facilities and separate devices in for each class of
service you have out there today, COEN (phonetic), POTS, PBX. We are not
built as separate networks. The vendors work hard in making it a
universal platform as it can.

No one vendor will ever keep up on an equal basis with everybody. That
is the reason they are all so competitive on what they try and generate.
But, yes, our affiliate will get exactly the same terms and conditions
as any CLEC on any of these. We will be totally non-discriminatory.

MS. PIES: We have a couple integrated voice and data CLEC providers here
today. And I was wondering if you could go into any of the unique
problems you face providing your services at a remote terminal, both the
standard ‑- the existing remote terminals and next generation remote
terminals.

MR. WIGGER: Yes. My name is Dan Wigger, and I\'m with Advanced Telecom
Group. And in fact, we have had an opportunity to review the network
architecture that looks like a shareable broadband. And I won\'t say
what the acronym is. And in fact, we do have a potential issue, and that
is one thing we haven\'t brought up yet.

And it is the market segment of ours that we provide service to in the
Soho market or telecommuter market, we provide lifeline POTS service
over our DSL stream that also allows them to connect remotely to the
office via a land connection, et cetera. And one of the immediate things
that we have seen ‑- and we have had some good dialogue with SBC ‑- is
how do we also provide that service that we provide from the CO to the
premise today that line- sharing per se, but our own line-sharing \--
the low-frequency and high-frequency as well \-- from the RT on a single
loop platform, as opposed to what perhaps the affiliate would do with
the ILEC infrastructure, and if that is a possibility.

That\'s one of the issues that we have seen in the challenges in the
architecture to date.

MR. MASTERS: Can I respond to that? We picked this issue up in the CLEC
forum we had in March. There is a lot of issues up in CLEC forums,
numerous meetings. AT&T brought this to us, and we looked at it. We
think we found a solution that was in the current architecture.

A lot of people have asked us why this thing keeps changing every week
and day. It is with constant feedback. And this is not exactly chartered
waters. We\'re moving very fast. We\'re taking feedback as fast as we
can and incorporating them in. It was a very minor architectural change,
actually. I think we will be able to satisfy our needs.

You have many niches \-- eruptions in niche, which is universal service,
the thing we provide both voice and data. And each of those represents
challenges. We will continue working with industry in that regard,
finding ways to accommodate them within the existing architecture as
rapidly as we can.

MS. PIES: I\'d like to hear from AT&T, that you mentioned that you found
a solution. And I was just wondering if you could explain what the
solution is.

MR. MASTERS: Okay. You want to take it, or you want me to? Okay.

MR. WIGGER: As far as the solution of line sharing from the remote
terminal ‑-

MR. MASTERS: Yes.

MR. WIGGER: ‑- to the premise? Again, we are in active dialogue. I think
the agreement, positively, is yes, we need to address that as far as the
lifeline type service. To date, technology wise, I don\'t know what the
solution is.

MR. MASTERS: Well, I apologize then. The problem is ‑- and it is the way
the line sharing orders are interpreted and laid in, that if you have ‑-
the data service from the OCD, and you also have the 8 DB voice loop
coming in. And the question was, can those both go to the same
colocation location, where a CLEC could put both those services on there
at the same time.

The initial interpretation of \"wound up\" was, that you could not do
that. And what wound up is, you wound up having two copper loops to a
residence rather than share ‑- having both services are provided on the
same copper loop.

What we have agreed to do is we are adding another option to our
broadband service offering, which we are on the verge of rolling out. I
think we started reviewing ‑- we are reviewing the various FCC staff
members and state commissions and CLECs as we speak ‑- is provide the
ability to have a single provider put both of those services on the same
copper pair that arrives at the house serving in view. The consumer sees
one pair with both voice and data on it.

Basically, what you are doing is you are taking the 8 DB voice path
along with the broadband service to the same colocation location, and
they are providing dialtone and data services on it.

MR. REISTER: I talked a little bit earlier about being able to do IP
based networking. Some of the very interesting and exciting capabilities
in integrated voice and data have to do with media gateway control
protocol, which is MGCP. Many of you are maybe more familiar with H248,
which is the ITU effort. But the capabilities ‑- and some of our
customers are trialing it, actually, in conjunction with some Lucent
equipment \-- some of the capabilities are really, really exciting in
terms of what you can do in terms of putting services in the network
that, frankly, blow away the capabilities of today\'s circuit switch
PSCN.

For example, some of our customers are interested in the capability of
creating call agents in the network that can do intelligent call-routing
and also act as an assistant to the subscriber. So some of you may be
familiar with, for example, some new PBXs where you have an automated
attendant where you can speak to the attendant, and the attendant can
call people for you and do things on behalf of you.

In the future, the network would have that similar capability. You could
pick up the phone, and instead of getting dialtone, you could get your
assistant \-- you know, Bob or Janet, your personal assistant \-- and
you can say I\'d like to call Doug Sicker, and you are on the phone with
Doug Sicker, and then you can say, I\'d like to conference in Jerome,
and the network will go and find you.

And a lot of these capabilities are not necessarily implemented around
VTOA, which is voice telephony over ATM, which is what many equipment
vendors and many ILECs are more focused on.

So when you ask about, what are the implications of doing integrated
voice and data, certainly some of our customers trialing this new
technology would very much like to be able to have those ability to do
intelligent packet forwarding at the edge.

MR. GETCHELL: This is Wayne Getchell from Nortel. From an integrated
voice and data access platform perspective, it is quite feasible to take
the copper loop and share either the voice or the data or both. Indeed,
it is also possible, obviously, in the data stream to embed voice,
either voice over ATM or voice over packet, and also provide that as
part of a complete service as well.

MR. WIGGER: Just to add clarity, the opportunity to add voice over ATM
via DSL we do today. But we also have a market segment once again that
we line-share and provide that lifeline-type POTS application. Our
customers understand if they lose commercial power at their premise
today via the VOATM DSL solution, they will essentially lose
communications, and that means access to emergency services.

Part of our market segment, we do deliver that service today. And from
our colocation facilities in the central office, if we refer to this
diagram, we have our own DLC placed in cages that we essentially
purchase a DSL qualified loop from the CO to the premise. That allows us
to impose that low frequency onto ‑- or through a low pass filter device
with our deployed architecture today, whereby that is a passive signal
on the loop to the customer premise.

We need an analog or a physical connection at the colocation, what is
termed a \"spot bay\", to do that.

And the only ‑- the remaining issue again is in order to continue to
provide that integrated service as well as lifeline type POTS, we are
just trying to understand how we get that same imposition of our low
frequency on the shared loop where we also in the ‑- let\'s say in the
most efficient sense, where we purchase an ADSL UNI for clarity, how
would we do that. That\'s the issue we have at hand.

MR. SICKER: Let\'s move on to the fourth series of questions. And \--

MR. COOPER: Excuse me. This is Doug Cooper from Network Services
Division. I would just like to clarify what on the adjacent colocation
and interconnection ‑- I heard, you know, some technical discussion. All
the technical options seem to be feasible, but I heard no way, no how on
the logistical rollout related to easement issues and reasons related to
economics.

I was just wondering whether or not a form of colocation hotel within
apartment buildings, multi-unit dwelling buildings, business offices
might change some of the topology of this, you know, whether it ‑- I
mean, avoiding the RT cabinet issue. I\'ll just toss it out there.

MR. BOWEN: I think that\'s definitely a different world. That is, if you
can ‑- well, we deal with commercial building owners all the time and,
you know, they oftentimes have space that they already have kind of
first generation cats out there living in.

So, you know, the ability to put a pizza box in a building is pretty
straightforward. It is the connectivity from there, you know, to the RTs
of the ILEC that is the issue then because if you have into a building,
then I\'m betting I am going to be asked to buy entrance facilities to
get to and from the actual RT itself.

So, you know, getting into a building certainly addresses the outside
plant placement issues.

MR. COOPER: Right.

MR. BOWEN: But then it creates its own set of how you get then from
there back to and from the RT or the SAI or wherever the copper you pick
up is, and wherever the fiber you hand back is.

MR. COOPER: Are those issues easier to deal with than adjacent
colocation of an RT? I mean, is that ‑- are they workable in terms ‑- it
seems that they are scaling down in terms of the degree of difficulty.

MR. BOWEN: Yes, they are easier to work with. But what you tend to find
is the commercial buildings tend to be ‑- not always, but tend to be
ones that are closer to the CO anyway.

MR. COOPER: Right.

MR. BOWEN: And you are talking about a topology that is trying to push
broadband out more into the residential neighborhoods, where you don\'t
tend to find so many businesses and therefore so many possibilities of
locating your stuff in a building.

So I think, you know, the core downtown area is where you tend to have
these commercial buildings where you can essentially place the
equipment. Partly the issue we are talking about here were these new
rollouts. It is much more push out and push the fiber farther out into
the neighborhoods and do it via cabinets and so forth, new or existing.
And there aren\'t too many buildings out there that you actually would
want to use as a site for your equipment.

MR. COOPER: I was thinking like the suburban office park model. I
mean \--

MR. BOWEN: There are some exceptions, sure. There are exceptions that -‑
you know, there are pockets of concentration and demand that are a ways
from the central office, sure. But those are ‑- if you are going to try
and reach a broad base of consumers, that is the exception instead of
the rule.

MR. COOPER: Okay. And then the rule was for logistical reasons,
economics, and reasons related to local zoning, that adjacent colocation
is just not a viable option for you. Is that ‑- I mean \--

MR. BOWEN: Yeah. I mean, in effect, what you are doing is you are
overbuilding a significant part of the cost component at least of a loop
network. And whether or not it natural monopoly or not ‑- I am not going
to argue that question right now. What I am saying is that the expense
in doing so for any size CLEC who wants to serve broadband is very
significant compared to the take rates you are going to get out of that
individual location.

MR. COOPER: Perhaps I was swayed by your comment about the Rhythms
sources.

MR. BOWEN: Well, we have a good chance of being the one that would be
able to do that. No. I don\'t think, frankly, for any CLEC that I am
aware of right now ‑- I have a hard time understanding the economics
working on a broad scale for adjacent RT kinds of construction.

MR. COOPER: Okay. Thank you.

MR. KYEES: Can I ask a question? Do you end up with a model where you
start off mainly relying on the platform with some colocation in the
newer remote terminals, and then as the embedded base gets retired in
remote terminals, you get a little bit more colocation within the
terminals with adjacent just being a sideline to it all?

MR. BOWEN: Well, again, I don\'t think you are ever going to see
adjacent colocation by data CLECs be a significant force in the real
world of the marketplace. Having said that, I think you will see us
wanting to use ‑- and I\'m not suggesting that people stop and rethink
all of their plans and do something different. It is going to be a
combination of what is out there and going forward.

So, for example, if there is space right now in CEVs and HUTs for
collocating our equipment, we\'ll use that. If they are building new
CEVs and RTs, and they are building 25 percent more space to handle
three to five more CLECs, we\'ll use that.

My biggest concern, frankly, is the situation you have where there is
new cabinets going out there that right now we know are not going to
work because there is a lot of those going out there right now. And
that\'s the concern that we have that we try to address that on a going
forward basis.

So really there is a combination of all of the things that are out there
because there is variance. There is a lot of varieties in terms of size
and type out there. So wherever it is possible to do it within the RT,
we want to do it. And we\'re also asking that for the newly deployed
RTs, that they be deployed so there is space in those for us as well.

MR. REISTER: And, Doug, my comment would be you would have to take some
kind of regulatory action to make the economics work out. So it would
have to be some kind of innovative regulatory solution where you create
a new business entity that is a real estate company, you know, you take
the ILEX real estate group and you spin it out as a separate entity. And
that entity owns the real estate and is responsible for things like
permitting and concrete and bricks and mortar, and has nothing to do
with, you know, telecommunications. And that entity then wants to
maximize their revenue stream and minimize their costs and so on. And
they would then lease space, you know, to the best dollar they could get
to both the ILEC as well as to the CLECs.

So if you had that kind of thing where you would have one entity, and by
virtue of having essentially 100 percent share because everybody would
be putting their telecom equipment in it, the economics would work out
for them. But I\'m not necessarily suggesting that.

MR. SICKER: That\'s way out of our \--

(Laughter)

MR. MASTERS: What would complicate this world even more is many of the
cabinets are going forward on public right of way, or even mounted on
poles. They don\'t have right of way at all. As you get smaller ones
that Bell South is doing, and we\'re doing in Ameritech.

MR. SICKER: Anyone else have any comments on those series of questions?

MR. KIEDERER: Maybe just one, you know, one final comment, and not to
rehash some of the things we talked about before. But we keep coming up
against this issue of the fact that, you know, nobody wants to build a
basic colocation. There are a whole host of issues with space. You know,
we talked about the fact that it may or may not make economic sense for
anybody to do this out of an RT location. Certainly, economics 101 would
tell you that, you know, what happens is determined on how much it is
going to cost you to deploy out there as well as the kind of penetration
you might get out there.

To the degree you fragment the customer base into a bunch of pieces, if
each one has to do an individual, you know, kind of construction, it is
going to make the economics even more shaky than they are, which sort of
leads you back at least to some degree maybe in the near term to the
kind of platform approach that SBC is proposing or the CLEC hotel
approach, you know, where you would consolidate the costs that would be
required to deploy out at a remote terminal location.

MR. BOWEN: Or there is the other solution, and that is just build them a
little bit bigger as you build them. That is, I\'m not going to deny
that there aren\'t scale economies for a terminal serving 2,000 or fewer
customers. There certainly are. But the answer, I don\'t think ‑- there
is something in between what you are suggesting, Charles. That is, on
the one hand you have got integrated platform. On the other hand, you
have got a whole bunch of who knows what, you know, adjacent RTs and so
forth.

In between those is a solution that says just build it a little bit
bigger so that your space is still your space, but you leave enough
space for other people to live within that same structure.

MR. OLSEN: Size 12 shoe for a size 8 foot.

MR. BOWEN: Pardon?

MR. OLSEN: A size 12 shoe and a size 8 foot.

MR. BOWEN: Yeah, see. Michael is always good with the metaphors. Michael
says a size 12 shoe and a size 8 foot. I think that is a good idea. That
is, yes, it costs a bit more in steel and concrete and space and so
forth to add an extra rack. But, frankly, it is a very small incremental
cost compared to doing a separate kind of stand-alone RT.

MR. KIEDERER: But even in adding an extra rack, that is only a piece of
the equation, as we talked about further. There is a lot of other work
that has to be done either by us or by you, other than adding a rack
space in order to deploy the actual service out at that location. It is
not just the rack.

MR. BOWEN: We would be happy to work with you to solve those problems.

MR. KIEDERER: And I guess the follow-on question again, we are here to
talk about technical, not economics. But are you willing to step up and
pay the third of the cost of doing that initially for us to deploy a
third larger piece of \--

MR. BOWEN: We have always said that we are happy to pay base rates for
all the things that we buy from you.

(Laughter)

(Simultaneous discussion)

MR. SICKER: Okay. I think we\'re digressing a little. What I would like
to do is cover four, ask if there are any other questions or anything
that anyone wants to say at the table, including the FCC staff, and then
open it up to the audience.

The first thing I want to talk about on four, what we are talking about
here is the plug and play, basically, the notion of a competitor coming
in with their own card and plugging it into a terminal and the standard
changes that would have to go about to allow this to happen.

My question, is there anybody here who is actually interested in this
approach? Okay. Why don\'t you ‑- why don\'t I ‑- Mike, could you \--

MR. OLSEN: I think that when you say this approach, we have to qualify
it. I mean, I think in a perfect world, we would all love to see ‑- go
back 50 years in the telecom business and see the universal chassis, and
we wouldn\'t be facing any of these questions. We would have all of the
economics of integration, have all the choice of facilities based
competition. So I don\'t think there is anyone here who wouldn\'t like
it.

The question is where we are today, can we get there without
substantially slowing deployment. And I think that raises some real
questions from both manufacturers, incumbents, and CLECs. Obviously, the
goals are balanced to keep the maximum of variation of facilities based
competition within the constraints of a timely deployment and the
economies of integration.

The business of RT is developed much like the razor business. You get
the chassis, and they have got you on the blades. We haven\'t seen
anyone doing more like the PC business with an open bus, and then you
can buy a variety of different port cards. But that is the reality of
the marketplace today. And regardless of our wishes, there is a big
embedded base out there, and we haven\'t seen anyone come forward with a
solution that would allow us simply to plug in cards and change the
ability to serve.

MR. SICKER: And I agree completely with you. But also, keep in mind that
the PC was ‑- it was a model that was chosen, a business model that was
chosen. This is a business model that has been chosen. But with that
said, I would like to hear what Steve has to say.

MR. BOWEN: We\'d like our current DSL vendors to be able to build cards
that plug into anybody\'s DLC. I don\'t care if it is Alcatel or AFC or
Fujitsu (phonetic) or Nortel or whomever. We would like to be able to
use the same ‑- what we think is good functionality from our current
vendors on this new platform. So we would like to have whatever is
required be done so that our vendors can build, instead of separate
DSLAMs that fit in racks in central offices, can build cards that plug
into the RTs that are going to be deployed out there.

MR. SICKER: Would any of the vendors like to address this?

MR. RANSOM: Well, I was just wondering ‑- Michael suggested he would
love to have this just like the PCs. I just wondered if he would like to
have the reliability of the RTs to be about that of the PCs as well.

(Laughter)

MR. RANSOM: Try intermixing various plug-in cards in your PC. Obviously,
if within Alcatel alone someone said why don\'t we have a universal back
plane on a going forward basis that we always use, we would laugh that
person out of the room. I mean, we have future platforms planned. And
one of the first things we do is try to innovate a new back plane with
new bandwidth. Maybe we\'ll go with ATM, maybe we\'ll have a separate
TDM bus, maybe we\'ll go with a pure IP bus.

We always come up with new designs. The notion that there would be some
universal back plane on a going forward basis that all of the vendors
would use seems laughable.

MR. SICKER: Gary?

MR. BOLTON: Yeah. I just wanted to make a comment. As far as the ‑- you
know, in saying plug-in cards, there is a number of ways to address
this. And really, the one is just to try to plug a card into another
vendor\'s box. But another way to look at is to actually provide an
upgrade system, in much the way that Copper Mountain was talking about
trying to put new mini-rams or things into the side of the boxes there.
There about 68-1/2 million lines currently served by remote terminals,
and about 8.8 million of those are light spans.

Light span seems to have dominated a lot of discussion, I think because
of the SPC petition. But there are a number of different products that
are out there. There are 28 million lines currently out deploying
products that do have different vendors just putting plugs in. And those
vendors range from Paradyne and Post Com and Charles Industries. There
are a number of different series of precedents set for existing legacy
products to be able to put plugs in.

But when you are putting DSL in, it is more than a plug, it is a full
system. So you are talking about not only to be able terminate the loop
with that technology, but you also have to have an ATM stat MOX
(phonetic) to be able to aggregate all of your ATM lines or your DSL
lines and then be able to back haul them to some type of backhaul
facility, whether it is a T1 or DS3 or whatever your facility.

So I would say in general, I wouldn\'t want the Commission to not ‑- to
disallow opportunities to address the installed base because, you know,
right now, nearly 40 percent ‑- maybe the number is a little bit lower.
But at least from RXK it is about 40 percent of the subscribers there
are served by RTs. And within two years, it is going to be more than
half of everybody is going to be served by RTs.

And so, you know, just looking forward, and I think we can\'t ignore the
installed base.

MS. MANCHESTER: So as far as bringing together a universal back plane, I
do agree with my colleague from Alcatel that having a universal back
plane in an RT is something that would be extremely timely to come up
with the standards -‑ time consuming rather to come up with the
standards, as well as extremely time consuming to actually prove in and
integrated all of the various line cards into a system approach.

Now having said that, we do in many times and on the request of our
customers work with other vendors to incorporate their technology into
our existing back plane, and more importantly, into the existing
operations, which we have heard is key to being able to put it out there
effectively, provision it, install it, and then maintain it going
forward. So that is an option that we exercise today and will continue
to exercise going forward.

I would also like to state that when we talk about opening up back
planes, we do need to, you know, talk about opening up back planes,
element management systems, and the whole system management and
integration. That is true from a remote terminal perspective, narrow
band and broad band. It also would be true ‑- I think you need to look
at it from the DSL, from the vendors who have some of the innovative
technology that you would be looking into putting in here.

So it is open back plane technology that you need to look at across the
board, and it is just as difficult across the board.

MR. REISTER: You know, I\'d really like to use the PC analogy to think
about this. If you think about a PC, a PC has plug-in cards that have
varying levels of functionality. But they all make use of the fact that
on the motherboard, you have got a ‑- you know, in the Wintel monopoly,
you have got a Pentium, a Pentium on there, and you have got the
Microsoft Windows operating system.

And if you think about it, so if you plugged in a video card to support
a video camera, the ability to display the video is going to be driven
by some software. And what Microsoft has done is created, you know, a
number of interrupts and hooks into their operating system to enable you
to create innovative applications.

So I think what we would need to do is ‑- you know, a plug-in is a
fairly simple electrical interface. But the point is the interface has
to go up the stack. What we would want the ability to do is get into the
so-called operating system of the loop carrier system so that we could
add features like, you know, IP routing, multiprotocol label switching,
and all of those things like that. And for those of you who know
equipment, you\'ll know exactly how ludicrous my suggestion is.

(Laughter)

MR. MASTERS: Somehow this process has got the idea that a circuit pack
as a piece of equipment is a service. And by plugging in this magic
available today thing, you immediately have a service. A service is an
end to end. We talk about CBR and UBR. All that only works if the entire
system is architected. Half the systems there are software. It takes a
huge amount of delivery process to make a service work. And I think of
concurrence around the word.

It is always a goal. All of us would like to have less circuit packs. We
would like to have only circuit pack do every service. I mean, I track
30,000 different type plugs a day in my business. I would like to have
one. It is costing gold. The question is how achievable it is versus the
cost of doing and the administrative cost of doing it.

The problem we have in \-- we tried that. We tried real hard. It makes
‑- I\'d like to have you buy it and not have me buy it, if you think
about it. But the cost of me managing one plug per owner per service in
48,000 RTs and doing it accurately, you guys talked to us before about
plug management, account management, and tracking of assets. This is a
very difficult subject versus the ability to get anything out of it.

If these guys can\'t build the plug to do it, why would we want to incur
all of that cost and drive that cost in to the service that drives the
price up in a very competitive market table. That is just the economics
of it.

I just don\'t see this as a short term goal that we can gain on
anything. At the same time, there is cases in the existing embedded base
we would love to find somebody that can plug in existing, like a series
five slick or slick 96 that gives me DSL to provide to these guys and
not to have to spend all of the money on doing something else.

We are always looking for that ‑- I don\'t want to kill innovation here
by any means. We are looking for people to bring things forward. It is
just in the huge embedded base we have today, which pretty well resides
over there with Nortel. The practicality in the short term doesn\'t seem
the reliability of building all of the back room systems and tracking
systems and management process capable of doing it.

MR. OLSEN: Doug, I think in part this original suggestion was what we
discussed earlier about the two levels of compensation, the service
level and the facilities level, and that when you have, and you are
naturally going to have, the vendors funneled through the incumbent,
there is a risk from the CLECs perspective that you lose the innovation
on the equipment vendor side because really, if the key in the full
purchaser and this monopsony (phonetic), the purchasing side of the
equation is going to be one vendor, you may lose that.

One way to overcome that is to allow plug and play cards. For example,
there are really ‑- I mean, what you are really trying to do in a large
scope is bring market forces to bear, and that can be either ‑- as I
said, directly or indirectly. But the key is if Alcatel has one buyer,
how do you make Alcatel innovate when North Point wants to provide video
streaming services, but the incumbent who purchases the equipment does
not.

And as I said, directly, by allowing us to go directly to Alcatel and
encourage that through fora ‑- but really, the key is to keep those
market forces in play. SBC wants that to happen because they want to
keep their costs down. One way to do it is through competition, the
other is through joint purchasing consortia. But we have got to make
sure that the vendors who are funneled continue to innovate at the
incredible pace that they have innovated so far.

And, obviously, I mean, Copper Mountain is one of our vendors, and we
can see, as we have had this discussion all of the kinds of things that
are on the pike. If Copper Mountain is boxed out of that funnel, where
does that innovation go?

MR. BOWEN: In a lot of ways, it is really a chicken and egg problem,
right? Until very recently, nobody was even talking about putting
anybody\'s cards into any RT or into DLC or anything else. And now ‑-
so, of course, if Phil Kyees goes to Neil Ransom and says, hey, Neil,
give me your specs so I can build a card to plug into your light span
units, Neil is going to say how about we go out for a drink. It is not
going to happen because you have got two competitors who basically are
not going to give their competitor their information. It is not going to
happen.

So it is a chicken and egg problem. I\'m telling you what Rhythms wants
as a DSL provider. We want our vendors to be able to have cards that
plug in. Of course there are problems right now because it hasn\'t
happened yet, nobody has made the request. The FCC hasn\'t required or
urged or done anything to encourage that to happen. So right now, yeah,
you cannot take a Paradyne card and plug it into an Alcatel box or a
Copper Mountain card and plug it in.

That isn\'t to say you couldn\'t do it. There are lots of ways to
approach those kinds of issues. What we are saying is what we would like
to have available to us for the reasons that Michael just gave.

MS. MANCHESTER: Steve, I would just like to comment on that, in that I
agree with you that one vendor just going to another vendor and saying,
hey, can you play nice with me, that doesn\'t always give us all the
right incentives to do that.

However, joint customers ‑- and in particular, we have both CLEC
customers and a lot of valued CLEC customers, as well as ILEC customers.
And when a customer comes to us with a particular request of being able
to have us work with another vendor for a platform for the benefit of
the customer, I do think that those things can be pushed along before
the drink.

MR. BOWEN: Well, that\'s a good sign.

MR. MASTERS: On that same subject, like I said earlier, we didn\'t start
building this network just to have the first service and the last
service be the one we are deploying now. It is designed to hit the mass
market and give a low price to a lot of providers to hit the large
market.

At the same time, we plan to aggressively add capability to this
platform and service as aggressively as the vendors can roll things out.
So there is the chicken and the egg thing. We\'re highly incented to do
that because if not, if you can\'t, then there will be more pressure to
find colocation space and things like this where other vendors can\'t.

MR. BOWEN: Well, I agree with that, and I think that your incentives are
even greater if we have the option ‑- let\'s Alcatel by themselves. If
we have the option to buy whatever hot card they have out there, HDSL2
card, that we want to roll right now, and you aren\'t so sure you are
ready to add to your platform, if we have the right to say okay, here is
the card, I want to plug it in today, that is going to move you along
even faster to offer your own platform based functionality.

MR. MASTERS: We should be highly incented to buy that card and provide
the service for you because once you step across the line of having to
your card, you bring a tremendous expense.

MR. BOWEN: Well, they have something that we call virtual colocation
right now, right, and we\'ll sell it to you.

MR. MASTERS: A card is not a piece of equipment, and it is not subject
to colocation, and neither is a plug slot.

MR. BOWEN: Oh, now, Wayne, let\'s not get into regulatory boxes here.

MR. MASTERS: Well, you tell me if a card can provide a service. It takes
the software, the shelf local software, it takes the card level, it
takes the system, the ATM instruction, the entire thing.

MR. BOWEN: Okay.

(Simultaneous discussion)

MR. MASTERS: ‑- card today and plug into a light span, and it is going
to work.

(Simultaneous discussion)

MR. BOWEN: We\'ll buy a copper sublooping UNI from you, and we\'ll buy a
broadband UNI from you, and we\'ll plug the card in, the Alcatel HDSL2
card in, and we\'ll be good.

MR. REISTER: Well, you may have to upgrade the entire software on the
whole platform.

MR. MASTERS: That\'s right.

MR. REISTER: And so you\'re upgrading their ‑-

MR. BOWEN: Well, I\'m not going to \--

MR. REISTER: The software is providing their services.

MR. BOWEN: I\'m not going to buy an Alcatel card that it isn\'t good to
go to the street with, right? That doesn\'t make any sense. If Alcatel
says I\'m good to support this new kind of card right now, but you
don\'t want to roll it, and I want to plug it in, I should be able to. I
should be able to say here is the functionality that the system will do
right now. I\'m sorry. How about Lucent box?

(Laughter)

MR. BOWEN: Now, we have got Lucent or Nortel. If I buy one of your cards
that has functionality that you may want to offer, I should be able to
say, okay, this system is supported by the vendor, and I want to plug it
in. And you want to sell it to me, right?

MR. MASTERS: But she has to sell a lot more than the card. She has to
sell the operating system, the chassis, the firmware, the software, the
entire package.

MS. MANCHESTER: So let me first say yes, I want to sell it to you.

(Laughter)

MR. MASTERS: Yes, she does.

MS. MANCHESTER: But it is true. I mean, we would end up ‑- we would end
up, like I said before, we develop that card, you integrate it into the
system from a hardware perspective as well as for an element management
perspective, possibly even a higher level network management. At that
point, if there is a handoff point at that point from the ILEC to the
CLEC, then that is where you all can kind of negotiate.

But if there is not ‑- and I would contend because it is a very
complicated service going back, the rest of the integration has to
happen before you can just turn up that service.

MR. MASTERS: Sure. In all seriousness, could we support this? Look at
your provisional flows. Today, the systems are designed to have a
provisioning flow to remove terminals for all slots, all plugs. They
would have to build provisioning flows down to the card level per card
per owner times 48,000 RTs.

All that technically can be done. The question is is it worth it versus
‑-

MR. BOWEN: Well, but you have got to do it out of the RT anyway when you
have got voice only cards and ADLU cards.

MR. MASTERS: But I don\'t have to do it per owner per service.

MR. BOWEN: You have got to do it per card, though.

MR. MASTERS: Okay. When you plug the card in that slot, you are
occupying a slot that feeds more than one customer.

MR. BOWEN: Two to four right now.

MR. MASTERS: That\'s right. And gaining more, 32 in Lucent\'s case.

MR. BOWEN: Right. But what you said was that all you are managing to is
the RT right now. That won\'t be the case when you deploy ADLU cards
right now in project ProlTel.

MR. MASTERS: On a profile basis. But all that gets into the definition
of capability. If you want to be able to treat that card like a complete
separate piece of equipment, then you suboptimize the RT down to that
level.

MR. BOWEN: Well, actually, if we have ‑- if we could plug in Alcatel
cards and they have four appearances per card right now, and we have ‑-
lawyer math, danger, danger ‑- if we have 11 customers right now.

MR. MASTERS: Okay.

MR. BOWEN: Right? We are going to have one spare appearance there. So
the last card is always going to be somewhat not full utilized. But all
the rest of them will be.

MR. MASTERS: If it goes to the right spot because those pairs are
hardwired to RT. They go to a particular SAI.

MR. BOWEN: Well, but they jump at the SAI.

MR. MASTERS: Right.

MR. BOWEN: They are going to be jumping at the SAI.

MR. MASTERS: If that slot shows up in the right SAI. I\'m not just
trying to argue. It is just you get into a very difficult ‑-

MR. BOWEN: Okay. So we\'ll have one ‑- the last card per SAI then, in
your channel bank. That\'s the issue. Four average SAIs per RT, right?
Four cards that may not be fully populated then.

MR. MASTERS: Is your card going to provide all of the POTS services and
the other service I need that slot for?

MR. BOWEN: If you ‑- what happened to handing the voice back, you know?

MR. SICKER: Well, this is degenerating.

(Simultaneous discussion)

MR. KYEES: This is totally separate, although I might be playing the
devil\'s advocate ‑- is that the reason why we are having this
discussion is because people have chosen to bundle advanced services
with the DLCRT that traditionally has been intended for voice. And there
are reasons for it. There is economies of scale that has been well
pointed out.

On the other hand, it has also created problems because now it is
difficult to obtain a level playing field. That\'s why we have been
talking for the past 15 minutes on this one topic. And maybe to widen
the box a little bit and think about it, are there ways that we can
unbundle one from the other and create a level playing field both for
the ILEC and the CLEC and also open to vendors being able to compete and
provide more innovation.

MR. BOWEN: Well, Neil is shaking his head no.

MR. RANSOM: A comment on that just from a technology standpoint ‑- there
is obviously only various marketing and regulatory issues. From a
technology standpoint, the force of the industry is to terminate the
whole loop on a card and to do that within the single chip. And that
technology is now becoming available to simply do a an ADD converter
across the entire spectrum, do the voice data separation processing in
the DSP in a single card. To try to do that separately, external
splitters and whatnot will die.

The economics of that in the long run are horrible. And what is going to
end up are single cards. That is the way things are going to happen. It
is just obvious from a technology standpoint. It is just such a
compelling technology solution that all of my competitors are building
similar approaches because it is the obvious technical approach.

MR. KYEES: So you are saying that CLECs cannot succeed then in what they
are attempting to do to be able to collocate in the same cabinet.

MR. RANSOM: Well, that\'s a different issue having to do with a space
and so forth in the cabinet. A CLEC, as in ATG, may offer this
integrated voice data service, of course, or they may offer a data
service for a customer who just wants a data service. But if you have an
integrated voice data service, and that is what the customers want, in
the long run to do that on separate cards with external splitters is not
a very economic approach.

MR. BOWEN: Nobody wants to stay there for the long run. I mean, for the
long run, there is not going to be separate analog POTS and then a data
channel above that. You are going to have voice writing, multiple voice
channels writing on the same broadband channel.

MR. OLSEN: Doug, I think the debate about plug-in cards and about the
availability of innovation, how quickly it be pushed out to competitors,
arises from some history. I mean, here we have vendors who are saying we
can do it and CLECs who are saying we want it, and the incumbent saying
you betcha we want to roll out, we have every incentive to do it. And I
think there is some skepticism on Steve\'s part, for example, that the
way you really respond as the sole vendor of this platform to CLEC
demands for new services and new capabilities, even if it allows us to
each your lunch in the marketplace. And there is some historical
skepticism about it that they\'ll respond to demand pull as a sole
vendor.

So again, it is marketplace economics. If you can introduce competition
with plug-in cards or some variety, it is competition push. I mean,
remember, DSL was around a long time before we were, but competition has
made it worth having several hundred people in the room. And so we have
got to find a way to make sure that when those commitments are made, for
example, not only will we give you the single PVC on the Alcatel
equipment, we\'ll give you two, we\'ll give you as many as you want,
that those leave this room and become concrete commitments and that the
flow of technology makes it all the way to the competitive community,
regardless of whether the incumbent intends to use it.

MR. SICKER: Okay. John Reel had some questions.

MR. REEL: Yeah. I\'d just like to go back a bit and ask about those ‑-
the back office systems and the operational problems, the operation
systems problems with using this kind of approach, whether it be various
line cards \--

MR. MASTERS: Pardon me. I have a clarification question. Are you talking
about the various type of cards or various owners of those cards?

MR. REEL: Well, either. Let\'s do one and then the other.

MR. MASTERS: Various types of cards exist today. As many vendors try,
they all try and have one card, but they all have several cards. We have
cards for calling service. We have cards for DS1s. We have cards for
POTS services. We have those. Those are all administered on kind of an a
card basis, not a the card basis. In other words, we know for our
forecast we had to have a certain number of POTS cards and a certain
number of DS1 cards and a certain number of various categories cards,
and there were systems of ways of getting those out there. And it is not
you quickly respond, and there are ways of assigning those.

The difficulty comes in when you start adding two more dimensions. Those
cards today are available to any customer for any service. If you start
saying they can only be used for one service per an owner, then those
cards are not available for anybody else, and you start having to have
‑- like we said, we had 34 CLECs in our last forum. If you start going
to a shelf that feeds only a certain number of houses, and you start
suboptimizing that, then you get into huge efficiencies.

The OSS is ‑- none of the OSSs today are designed to take in ownership.
So I\'d have to have ‑- this plug is to this location for these
services, to this particular owner, all in the assignment algorithm. The
CLECs would have a huge set of problems themselves. They would have to
know when the customer called in they already had a card, last lot,
first lot, there or not, a spare port, who can be assigned to it or not.
And if not, how do they get a card to us. If it is really working,
preprovisioning at increased intervals. It just has a lot of back office
things that haven\'t been today.

In the vendor system, depending upon how much access people want to that
card ‑- if it is their card, they want to have separate alarms, separate
provisioning systems, separate maintenance systems. You can get this to
the extreme that you have to reartic (phonetic) the entire operating
system of the RT to get to the extreme. It all gets you in definition of
ownership.

What I am really hearing, though, is if Alcatel or Lucent makes a card
that gives a service, how can the CLECs be assured that card gets
introduced into the network? I think that is really the essence of the
problem over ownership. I don\'t think people like to own things. They
like to be able to control things more than anything else.

We are highly incented to incorporate services in as soon as possible to
avoid all of the disadvantages of not doing that. Not doing it is the
consumer doesn\'t get something they want, and we get forced into a lot
of other methods, colocation hotels, physical things, to provide
ultimate space. Now the odds of a vendor providing every service all the
time is going to be a problem.

MR. REEL: We can begin virtual colocation as soon as the new innovative
card becomes available just as good for a CLEC as physical colocation
where you have actual control over the card and can go in and do your
own maintenance.

MR. BOWEN: Well, I am going to speak for Rhythms only on this and ask my
colleagues to speak for their own companies. But what we are talking
about here is, yes, there are changes required to OSS to support these
things. We would be, I think, happy ‑- and again, this is just the
single vendor, you know, the same vendor\'s card as the box I am talking
about here. I don\'t want to, you know, push aside too far other kinds
of plug compatibility kinds of issues.

But speaking just to the same vendor, same card issue, virtual
colocation, I think, can work quite well assuming again that the prices
are economic prices for this reason. There may be 34 CLECs out there,
but there aren\'t 34 vendors, right? In this case, we are talking about
a single vendor offering two or three or four five, or count them on
both hands maximum, kinds of DSL. And so with virtual colocation, these
are not insurmountable problems. You warehouse these cards just like you
warehouse anything else. You put a certain number on the trucks that
roll out to the field. You know after some period of time how many you
need to stock.

Whey they go bad, you don\'t go out there and mess with them. You pull
out the old one, you put a new one in. When it fails, if it fails, you
just need to go out there and plug a new one and bring the old one back.

So virtual colocation lets the ILECs, first of all, control and minimize
the different number of cards they have to carry around, right. And
frankly, you know, you can have an inventory of cards, in effect a pool,
so that you have ‑- let\'s pick on Lucent. You have Lucent cards that
support ADSL or HDSL2 on a virtual colocation paradigm. You say, okay, I
am Rhythms. I want you to place HDSL2 cards via virtual colocation,
whether or not the ILEC wants to use that particular flavor or not of
DSL. I want to be able to place those cards.

Virtual is a good way to do that. That is, it doesn\'t require us to go
out with our trucks, escorted or not, or, you know, smart card swiped or
not at the RT. It lets us still maintain that kind of choice of a vendor
technology. And in effect, the ILEC still owns the card because we have
sold it to him for a dollar.

So virtual colocation in an RT kind of world works pretty well, as a
matter of fact.

MR. McNAMARA: Virtual colocation creates exactly the same impediments
and obstacles to OSS development as physical colocation does. We still
have to create structures to manage different ownership of individual
cards. The real issue here is whether or not if new cards are available,
how quickly can you introduce them. I\'ll commit from the standpoint of
Bell South, we will introduce these as soon as practicable. The issue
becomes how do we recover our costs first for the card itself and also
for the shared infrastructure that is used. And that is going to be a
problem, a common problem, independent of whether it is shared physical
colocation, virtual colocation, or unbundled access.

MR. BOWEN: Well, see, actually, if we own the cards and sell them to you
for a dollar, we take all of the risks of those cards not being utilized
or utilized less than 100 percent of the appearances on that card. We
talk about OSS modifications. Yeah, you have got to add a field that
says who is the owner of this card that is going to track that.

MR. McNAMARA: We may well be willing to do that. I mean, I\'m not really
too concerned about the actual ownership of the card itself. I\'m
concerned about how much of the shared infrastructure is being utilized
by virtue of the fact that that card is in place.

MR. MASTERS: If you had a card with four ports, the first CLEC to the
first port. A second CLEC comes in. Instead of being able to assign that
to the next port on the card, as you would in the shared environment,
you would have to have a different card for a different CLEC, and third,
fourth, and fifth. You might have 60 percent of your cards spare. But
you have basically suboptimized the box where you run out of slots
versus \--

MR. BOWEN: No. We went through this before. You are only talking about
the last card that each CLEC owns. It won\'t be 100 percent popular
because as soon as you have four customers, you have used up one of your
cards.

MR. MASTERS: No. But each slot is not universally applicable to all
customers.

MR. McNAMARA: That shouldn\'t be an issue really. I think when we are
talking about \-- if he is using a slot, the cost is per slot. And the
fact that maybe four lines of capacity is eaten up, that\'s going to be
part of the price. The issue is also the ATM infrastructure, how much of
the infrastructure is going to be allocated to that particular slot or
per line on an individual slot.

MR. SICKER: We actually have to move on because we ‑- there may be other
questions that FCC staff has. And we also need to open it up to the
audience. So, anyone? Jerry, do you have anything that you would like
to?

MR. STANSHINE: I just had one. We had a number of people who mentioned
that at least in their view, they thought the most inexpensive way to
support DSL service there there is an embedded RT that is not DSL
compatible might be to put a DSLAM up next to it rather than build an
entire new RT. And I was just wondering, do you find it less expensive
to put an entire RT there, or just trying to understand that approach
that some people are taking with the alternative?

MR. MASTERS: I\'ll respond to that. We studied that very hard.
Obviously, it would have been a lot easier if we could have just taken a
pizza sized box and stick it somewhere in an RT and then instantly have
solved the problem. It gets into your penetration levels.

Also, each slots are hardwired, and there is not an access point to the
RT, except to a certain subset.

MR. STANSHINE: Sorry. What did you \--

MR. MASTERS: There is not an access point to all copper sub-loops at the
RT. Each slot is dedicated to a certain number of living units or to a
certain SAI box. We found that with the penetration levels we were
looking at, able to get in there, it was more economical to upgrade the
box particularly, not increase a structure on the outside because you
have to have parallel fiber facilities, you have to have different OSSs
for that other box. You have to treat it exactly as you would if you did
the adjacent structure.

MR. STANSHINE: So you are saying you are able to do this without putting
up a second box for a while? You are just going to survive with the one
box that is already ‑‑

MR. MASTERS: If you are trying to do a very small number of customers in
one location, the box makes some sense. If you are trying to do a very
large number of customers, you get past the point of economics.

MR. SICKER: Johanna?

MS. MIKES: I\'d just like to return briefly to the notion of maintaining
existing fiber, where the ILEC is deploying ‑- I mean maintaining
existing copper where the ILEC is deploying fiber in your remote
terminals. And first, I would like to ask the CLECs, are competitors at
all interested in that existing fiber? Would it be useful from your
perspective? And then I would like to ask the incumbents, does pushing
this fiber out to their remote terminals affect a CLEC\'s ability to
offer all services to end users, including T1s?

MR. OLSEN: We are unequivocally interesting in maintaining that copper.
I mean, it is an incredible asset. It was written off years ago, and now
it is how we are going to bring broadband to half the country at least.
So it is essential, not just that it be left in the ground, but that it
be serviceable. So I think SBC has already made a commitment, though a
somewhat guarded commitment in that regard. We want to see that firmed
up because that makes sure that the fiber deployment is complementary to
and not in lieu of the current deployment of advanced services we have
today.

MR. WIGGER: In addition to that, the maintenance of that copper plant,
when the upgrade or the overlay of the network is put in place, that
frees up copper facilities back towards the CO. And in many instances
today in some of our territories, we attempt to order a DSL qualified
loop from the CO and find that there is a current CSA environment that
carrier serving area where remote terminal feeds those groups of
subscribers or businesses, where in effect we can\'t buy a dry loop or
copper loop out to that area, yet it lies within the traditional 18
kilofoot range of DSL deployment.

So in fact, we would like to see that copper plant maintained so we can
reach those customers that we can\'t reach today.

MR. BOWEN: Let me just add that it depends on which copper you are
talking about. Leaving copper in place that is running with bridge tap
included, you know, 25-, 30,000, 35,000 feet, there is no point to leave
that in place because all you can run over that right now is ISDN or
IDSL. So that doesn\'t do us any good, frankly, as DSL carriers. Our
working maximum for any usefully broadband kind of DSL is in the 20- to
23,000 foot range, at the top end.

So we definitely agree that for the shorter copper, there is no reason
‑- you know, we would like to have that stay up there. But for the long
copper to stay in place, the copper beyond, say, you know, the low
\'20s, we frankly don\'t want to pull of a bunch of lumped coils and
excessive bridge tap and so forth. That is going to cost us way too
much. That is going to cost these companies way too much to do that.

That kind of plant, frankly, I think is better retired and replaced with
the fiber fed DLC kind of configuration.

MR. ROSENSTEIN: In fact, just one more comment. Keep in mind that we
have scaled our deployment in the COs for an estimated number of, you
know, subscribers. If a lot of this copper gets reterminated at the
carriers, we now have fewer people we can reach from the CO. So it
changes the economics of what we built the business plan on in the first
place. So it is just worth mentioning.

MR. MASTERS: I\'d take it first, I guess. Our current plan, this is an
overlay network. We are not retiring any copper, any bolt bases or
anything. As we said before, as copper becomes too defective to be
maintained, it is retired. We are not changing our retirement plans
before or after. They are what they are and have been.

Again, we can use that copper for POTS service. Remember, half the
customers in these RTs probably will never have any desire for
broadband. And those POTS service will be fed over the copper as a first
choice. We only go to the DLC if it is all exhausted for POTS, growth,
and for broadband services.

MS. MIKES: So this doesn\'t look like just CLECs ability to provide any
services.

MR. MASTERS: It is kind of the way all services have been arrived. In
many cases, you had copper first, then you had this little carrier, then
you had the next, and it just keeps building up. You retire it basically
when it comes uneconomic. The same thing on the interoffice. We have
copper cables unfortunately left in the interoffice world at the same
time. But they are still economical to keep in service.

MR. McNAMARA: Just one more thing. Please keep in mind the issue of
spectrum management. If there is also DSL in that NRT site and it is
sharing a distribution facility, the services that launch from a central
office are in serious jeopardy.

MR. BOWEN: We, of course, don\'t agree with that. We think ‑- unless it
is analog AMIT1s. In fact, there is a ballot about to go out from T1 and
E1 that is going to specify the DSL flavors. And they will basically
live and prosper together in the loop plant without any special
techniques besides keeping the AMIT1s off by themselves or in effect
retiring them, which I think SBC is going to be doing as part of their
project protocol.

MR. OLSEN: It sounds very encouraging about the existing copper. I think
we just need to understand clearly what the existing retirement plans
are. And I was concerned when Charles said earlier that while we may
retire copper, we will leave your existing DSL customers up. I mean, the
DSL customers today are a fraction of the market that is going to be
served.

It is more important ‑‑ it is essential in fact ‑- that we make sure
that we leave the copper that is in the ground that addresses potential
customers, not just those who are up, so that people who today could get
it will still be able to get it tomorrow should they choose to do so.

MR. KIEDERER: Well, maybe you misunderstood what I said earlier. The
copper that is in place we have no intention of yanking out, especially
we can\'t yank it out if it has unbundled loops on it based on the
current guidelines, okay? Whether or not we choose to use that, okay, in
the future for anything else, you know, we don\'t know at this point.

What I will say, however, from an overall engineering and architecture
perspective, if we had the luxury of doing a desert start today, nobody
in their right mind would put in copper today. We would drive fibers as
close to the home as we possibly could.

All of the studies that have been done in terms of the pricing of loops
have been priced on that forward looking design. We then run into the
anomaly of trying to deal with what some may consider an interim copper
based technology, this DSL DSLAM type of equipment. And the associated
pricing and support of that copper network under the guidance of a
forward looking TORIC (phonetic) fiber structure and how do those two
weigh against each other, how is the cost recovery done, how is the dual
plant maintained on a going forward basis.

MR. SICKER: I should cut in again. I apologize. We are really kind of
limited in time for the audience. But I would like to ask if anyone from
the audience does have any questions.

AUDIENCE MEMBER: Hi. My name is (inaudible). I am with Nortel Networks.
And I also am a chairman of the DSL forum marketing committee.

One section of the industry is not represented here, and I wanted us to
keep in mind that section, which is the modem manufacturers. They have a
terrible time right now developing to interface with products that are
deployed out there. And we need to ensure that whatever solution we
have, it is standards based and that the interoperability is addressed.

MR. SICKER: Could you stay at the microphone? How are you ‑- in the DSL
forum, are you addressing this?

AUDIENCE MEMBER: We developed ‑- we have interoperability activities
right now running at the University of New Hampshire. And at Supercom
and other events, we have interoperabilities. But what is being deployed
out there is not necessarily what goes to these labs. So there are still
vendors out there that deploy proprietary type of products.

MR. OLSEN: As the DSL CLECs go feet first into the consumer market, one
of the most important things about scaling that market is the ability of
the consumer to buy lots of different modems to plug into the DSLAMs
that are in the office. That interoperability drives down price, so you
can go to CompUSA, put your modem under your arm, go home, and have your
DSL.

Some vendors have made extraordinary efforts in that regard. I know
Copper Mountain\'s products are widely interoperable. Some are less so.
And I think, for example, Alcatel\'s was the least, and is increasing
its interoperability. But that is a key component. Of course, it is the
exact same issue, that it has to be funneled in a way that the vendors
respond to those market demands. And I know that there are an increasing
number of CPE vendors that speak to the Alcatel DSLAM. But that\'s an
important point. It comes back to the same issue about maintaining
facilities based competition somewhere in the network.

MR. RANSOM: I certainly agree with Michael, except for one point.
Alcatel has always been named the most interoperable. We interoperate
with virtually every ADSL compliant modem out there. So I\'m somewhat
surprised that you would suggest otherwise.

MR. REISTER: I would just comment that ‑- and this should definitely not
be a vendor thing. But the interoperability issues are essentially the
same whether it is RT based or CO based. There might be a couple of
things that, you know, you might innovate on in this voice world going
forward. But I don\'t really see any difference in the issues from an RT
versus a CO perspective. So I don\'t know that we have to consider
interoperability specifically for RT.

MR. SICKER: Are there other questions from the audience? Well, maybe we
should turn it over to the \--

MR. MASTERS: May I have one last comment?

MR. SICKER: Sure.

MR. MASTERS: Technicality. We have used words intermixed here. I just
want to make sure we are kind of straight on the words. Colocation is
only required for equipment necessary for access to UNIs. A plug-in card
is not a piece of equipment. It by itself cannot access a UNI, just to
make it real clear. We are clear that a plug-in card sitting on a table
by itself can\'t do anything. It is like a water pump on an engine. It
is a critical component, but it is part of the system.

We talked a lot about today when you address these services, you have to
address the NDN service requirements, otherwise nothing is going to
work, and we are going to spend a lot of money doing all of the wrong
things.

MR. SICKER: Okay.

MR. BOWEN: A card by itself is not a service. A DSLAM by itself is not a
service. You put a DSLAM on the card, it is the same thing. So we are
saying this is how we want to be able to access UNIs.

MR. SICKER: Yeah. You know what? Let\'s not go into this because we are
not worrying about what is a UNI, what is not a UNI. We really don\'t
want to do this. That\'s outside of the purview of this. Yeah.

MR. RANSOM: If I could make a final statement. We have talked a lot
about the colocation issue. And it seems like there is possibilities
that CEVs and HUTs \-- obviously, a problem with the shrink wrapped
cabinets. We have talked about the possibility of forcing the ILECs to
put in large cabinets with additional power, additional ADM MONX
(phonetic) capabilities, copper distribution frame, and so forth. And
speaking from Alcatel, that sounds great. We have a chance to sell them
a lot more expensive equipment for these sites, and that is great,
although I\'ll admit guilty as charged when Charlie says that, yeah, you
talk about that, but that would take you design cycles and whatnot, and
that takes a long time to happen, and that is absolutely true, and
guilty as charged.

But quite frankly, to think that that ‑- the reality is that most
customers are served by existing ones, not the ones that are going to be
installed. And the new ones that are going to be installed, we have seen
from just the orders we are getting, they are getting very small. And
once you get down to small equipment, even as Bell South is deploying in
tiny handholds to say, well, you just put in another rack of equipment
in that side is crazy.

There is just very little that is going to be done in the future as we
get to very small sites to talk of colocation and tiny little boxes that
sit out in the street. It is just odd.

So think of that as you think of whatever rules to put forward. The
shared platform does seem to make a lot of sense. And, obviously we need
a forum to get discussion. The CLECs are both our customer and our
customer\'s customer, as Steve would point out. And we are very
interested in their needs so that we can make sure those needs are met
in these shared platforms.

MR. SICKER: Okay. I\'d like to thank everybody, and the meeting is
adjourned.

(Whereupon, at 4:05 p.m., the meeting was adjourned.)

//

//

//

//

//

//

//

//

**[REPORTER\'S CERTIFICATE]{.underline}**

**FCC DOCKET NO.**: N/A

**CASE TITLE**: COMPETITIVE ACCESS

**HEARING DATE**: May 10, 2000

**LOCATION**: Washington, DC

I hereby certify that the proceedings and evidence are contained fully
and accurately on the tapes and notes reported by me at the hearing in
the above case before the Federal Communications Commission.

Date: \_5-10-00\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Sharon Cook

Official Reporter

Heritage Reporting Corporation

1220 L Street, N.W., Suite 600

Washington, D.C. 20005-4018

**[TRANSCRIBER\'S CERTIFICATE]{.underline}**

I hereby certify that the proceedings and evidence were fully and
accurately transcribed from the tapes and notes provided by the above
named reporter in the above case before the Federal Communications
Commission.

Date: \_5-10-00\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Mary Ellen-Feinberg

Official Transcriber

Heritage Reporting Corporation

**[PROOFREADER\'S CERTIFICATE]{.underline}**

I hereby certify that the transcript of the proceedings and evidence in
the above referenced case that was held before the Federal
Communications Commission was proofread on the date specified below.

Date: \_5-24-00\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Glenn Arkin

Official Proofreader

Heritage Reporting Corporation