|Publication number||US5386417 A|
|Application number||US 08/113,496|
|Publication date||Jan 31, 1995|
|Filing date||Aug 27, 1993|
|Priority date||Mar 18, 1993|
|Also published as||CA2115089A1, CA2115089C, EP0616476A2, EP0616476A3|
|Publication number||08113496, 113496, US 5386417 A, US 5386417A, US-A-5386417, US5386417 A, US5386417A|
|Inventors||Thomas H. Daugherty, Dennis L. DeBruler, Daniel S. Greenberg, David J. Hodgdon, Douglas J. Murphy|
|Original Assignee||At&T Corp.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Non-Patent Citations (6), Referenced by (68), Classifications (12), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This is a continuation-in-part of the U.S. patent application Ser. No. 08/033,478, filed Mar. 18, 1993, entitled "Method and Apparatus for Establishing Connections in a Communications Access Network", now abandoned.
The present invention relates to telecommunications systems and, in particular, to communications access networks including, for example, the telephone local loop plant.
The access network interconnecting, for example, a telephone central office and terminal equipment at customer premises locations is conventionally referred to as the "local loop plant." This network is comprised, for each connection or "local loop," of a series of local loop segments extending from within the central office through various cross-connection elements to endpoints connected to the customer premises locations. In strictly-wire-pair-based arrangements, these cross-connection elements typically include the main distributing frame within the central office building; one or more feeder/distribution interfaces (FDIs), typically housed in grade-level pedestal cabinets or huts, or in subterranean vaults; and a serving terminal, typically housed in an enclosure mounted on a utility pole, or on or within a building, and serving as the point from which extend wire "drop pairs," or "drops," serving perhaps a half-dozen customers. Administrative database systems such as those known as COSMOS, LFACS and PREMIS are used by the local telephone companies to maintain detailed data for each local loop, specifying all of its wire pairs so that telephone craftpersons can, for example, a) identify which wire pairs between any two cross-connection elements are available for use as additional local loops are added, and b) troubleshoot reported local loop failures.
The process of provisioning new wire-pair-based local loops and performing maintenance on the existing local loops is an expensive one. The principal source of expense is the labor cost associated with the need for craftpersons to make manual cross-connections in the FDIs and serving terminals, along with the travel time. In turn, a major part of this labor cost arises out of the fact that a not-insignificant portion of the administrative database data is inaccurate, leading to mistakes and re-works in the course of a) provisioning new local loops, and b) deprovisioning of no-longer-needed, existing loops. The data inaccuracies can arise in many ways. For example, incorrect data may be reported from the field, as happens when the wire pairs used to establish local loop connections are mis-reported. Or, the data may be inaccurately entered by clerks to whom the craftpersons report the data. At some point, the overall level of inaccuracy in the databases becomes so great that the telephone company has little choice but to deploy a significant amount of resources to go out, survey the entire loop plant, and correct the data.
Over time, digital loop carrier (DLC) and fiber-in-the-loop (FITL) systems have begun to replace at least a portion of the wire-pair-based local loop plant. The most advanced of such systems can obviate some of the problems described above. For example, these systems feature active cross-connection elements whose cross-connections can be controlled and kept track of remotely, and automatically, from a central provisioning system. However, problems remain. For example, there still remains the need for a database to keep track of the cross-connections thus made. Additionally, the remote provisioning capability itself brings with it the need to administer an added infrastructure--most notably the data links by which the central provisioning system communicates with the DLC and/or FITL systems. Moreover, manual data entry is still required when, for example, the capabilities and/or capacities of the various access network elements are changed.
It is to the amelioration of the above and other problems that the present invention is directed.
In accordance with the invention, cross-connections between the switching office and any particular endpoint served by the switching office are set up on a call-by-call basis to establish a connection based on information generated from within the access network itself. The invention thus avoids the prior art's need for a centralized loop assignment database/provisioning system to keep track of manually made cross-connections or to carry out centrally controlled cross-connection administration.
In preferred embodiments, communications between the switching office and a particular endpoint of the access network are established using the invention set forth in our co-pending, commonly assigned U.S. patent application entitled, "Communications Access Network Routing," Ser. No. 113,481 filed of even date herewith. In accordance with that technique, the communications are established by routing an identification of that endpoint from the switching office through the access network via the use of previously stored muting information, that information identifying, at the switching office and at each of a plurality of packet switching elements within the access network, a particular downstream link over which the endpoint can ultimately be reached. In particular embodiments, each packet switching element is co-located with a cross-connection element in an access network node and the routing information stored therein is used to set up the connection, segment-by-segment, starting from the switching office. In other embodiments, in which the packet switching elements and the cross-connection elements need not be co-located, the routing information is used to packet-switch messages from the switching office to the particular endpoint. Responsive to receipt of such messages, the endpoint thereupon initiates the setting up of the connection through the cross-connection elements to carry the call--illustratively beginning from the endpoint itself and working its way back to the switching office.
FIG. 1 shows a telecommunications system which includes a strictly wire-pair-based communications access network of a type known in the prior art--illustratively a local loop plant which interconnects a telephone central office with various telephone customer premises locations;
FIG. 2 shows a telecommunications system which includes another prior art type of communications access network in which digital loop carrier (DLC) and fiber-in-the-loop (FITL) systems replace a major portion of the wire-pair infrastructure;
FIG. 3 shows a telecommunications system which includes a communications access network--again in the context of a local loop plant--embodying the principles of the present invention;
FIG. 4 shows, in simplified form, records maintained by prior art administrative database systems containing data about the communications access network of FIGS. 1 and 2;
FIG. 5 is a cross-connection table maintained within the remote terminal shown in the network of FIG. 2;
FIG. 6 shows the format of an access network endpoint identifier used within the access network of FIG. 3; and
FIGS. 7-9 show tables used to route signaling messages within the access network of FIG. 3.
in the prior art arrangement of FIG. 1, a plurality of telephone customer premises locations 90j, j=1 . . . M, are interconnected with a telephone central office 10 via a strictly wire-pair-based local loop plant. Telephone central office 10 includes, among its various components, central office switch 11 and switch line unit 114. The latter includes switch termination points OEi, i=1 . . . N, each associated with a particular telephone number TNi served by that central office. The abbreviation "OE" is a standard telephony term meaning "originating equipment." Central office switch 11 includes a switch controller 110 which, in turn, includes a directory number translation table 111 that is administered from a central provisioning system 80 via a link 85. When a telephone call terminating on a particular TNi served by telephone central office 10 is received on an incoming trunk, such as trunk 8, switch controller 110 translates the TNi into the associated OEi, using directory number translation table 111. The call is then connected to that OEi.
Each switch termination point OEi, in turn, is connected to an associated customer premises location 90j via a local loop comprising a series of wire pairs extending from OEi through various access network nodes, or so-called cross-connection elements. These cross connection elements include main distributing frame 15 within the central office building itself; one or more--in this case, two--feeder/distribution interfaces (FDIs) 20 and 30; and serving terminal 40, the latter being the terminating node. (In urban environments, a local loop may comprise a direct link from the main distributing frame to the serving terminal, with no intervening FDI.) The cables 21 containing wire pairs that connect main distributing frame 15 directly to an FDI are conventionally referred to as feeder cables or F1 cables. The cables containing wire pairs that interconnect all subsequent cross-connection elements are conventionally referred to as distribution cables, with the distribution cables between each successive pair of cross-connection elements being called F2, F3, . . . cables, respectively. Thus the particular one of cables 21 interconnecting main distributing frame 15 with FDI 20 is an F1 cable; the particular one of cables 31 interconnecting FDI 20 with FDI 30 is an F2 cable; and the particular one of cables 41 interconnecting FDI 30 with serving terminal 40 is an F3 cable. Wire pairs 91j interconnecting serving terminal 40 with customer premises locations 90j are conventionally referred to as "drop pairs" or, more simply, "drops," it being assumed in this example that each customer premises location is served by a single drop.
Not shown in the FIG. are numerous other FDIs and serving terminals which are interconnected back through to main distributing frame 15 in a conventional hierarchical arrangement via various ones of feeder cables 21 and distribution cables 31 and 41.
The local telephone company that operates central office 10 maintains detailed data specifying which wire pairs within the various cables, and which drop pairs, comprise any particular local loop. Typically, the local exchange carriers owned by the Regional Bell Operating Companies (RBOCs) maintain this data in three administrative database systems, known as COSMOS, LFACS, and PREMIS. As shown in simplified form in FIG. 4, each of these database systems stores data for different segments of the local loops. The COSMOS system, in particular, maintains a record for that segment of each local loop which starts with the OE and terminates on the first FDI. The COSMOS record, more specifically, identifies the OE, the TN, and the F1 pair. The LFACS system maintains a record for that segment of the local loop which comprises the wire pairs in each of the feeder and distribution cables, and thus identifies the F1 pair, the F2 pair, etc. The PREMIS system maintains a record for the drop segment of each of the local loops that extends to a particular customer premises location. The PREMIS record, more specifically, identifies the street address of the customer premises location, the drop pair(s) associated with that location, the serving terminal from which the drop pairs extend, and the TN and OE associated with each drop pair. Additionally, the record in each of the databases further includes, as shown, a "condition" flag indicating the assignment status of the local loop segment in question, such as "assigned," "spare," or "faulty."
Although each local loop must have an associated record in each of the three databases, the opposite is not true. Many of the records in these databases are not associated with any currently provisioned local loop but, rather, exist as unassigned local loop segments. For example, when service to a particular customer premises location is turned off, the records in the three databases associated with that local loop are not necessarily deleted. Rather, they may be marked as "spare." Thereafter any one or more of the local loop segments identified by those records, or portions thereof, may be assigned to new, subsequently provisioned local loops, while possibly leaving one or more of such segments or segment portions in the "spare" status. As alluded to earlier, it is often the case that records are created and updated in these databases in a less-than-meticulous and less-than-fully-regularized way, leading to the many database errors which make this approach to local loop administration a cumbersome and expensive one.
As noted above, digital loop carrier (DLC) and fiber-in-the-loop (FITL) systems have begun to replace at least a portion of the wire-pair-based local loop plant. Advantageously, the most advanced of such systems known in the art--which are only now starting to be deployed in the field--obviate many of the problems described above. For example, these systems feature active cross-connection elements whose cross-connections can be controlled and kept track of remotely from a central provisioning system.
A local loop plant of this type is shown in FIG. 2. Again, the telephone customer premises locations 90j are interconnected with a telephone central office 10, whose switch 11 has a switch controller 110 which, in turn, includes directory number translation table 111. The access network nodes are no longer wire-pair-based passive, e.g., mechanical, cross-connection elements, however, but rather are active cross-connection elements--referred to as remote terminals, or RTs, and distant terminals, or DTs, serving as the terminating nodes. The RTs and DTs are housed similarly to FDIs and serving terminals, respectively, as described above.
Specifically in FIG. 2, communications between the central office switch and a particular one of the RTs--illustratively, RT 50--are by way of a DLC system comprised of a digital carrier line unit (DCLU) 115 in the switch and RT 50, the latter including a trunk unit (TU) 51. These units are interconnected by time-division-multiplexed DLC link 45, illustratively comprised of five T1 lines. Communications between RT 50 and a particular one of the DTs--illustratively, DT 70--are by way of a FITL system comprised of fiber channel units 59 and 71 in the RT and DT, respectively, which are interconnected by time-division-multiplexed FITL link 65. The latter is illustratively comprised of a pair of loop distribution optical fibers. The drop pairs 91j serve as single-channel links between DT 70 and the various customer premises locations. They are permanently connected to, and terminate within, DT 70 at line terminations, or "service ports," 79j, whose physical connection points to the drop pairs 91j are defined herein as being the local loop endpoints served by the switch.
Not shown in FIG. 2 are numerous other RTs and DTs which are interconnected back through to DCLU 115 in a conventional hierarchical arrangement via various DLC and FITL links that are like links 45 and 65.
Systems of this type do not associate a physical switch termination point OEi with each TNi as in the arrangement of FIG. 1. Rather, there is associated with each TNi a particular timeslot on link 45, herein designated as timeslot OEi. In this example, timeslot OEi is a particular timeslot that is selected for the TNi when the local loop is provisioned, and it does not change over time. Alternatively, in so-called "concentrating" DLC systems, each OEi represents a provisioned "virtual" timeslot which, on a call-by-call basis, is assigned to a timeslot by the DLC equipment and/or by switch 11. Once the OEi associated with a particular TNi for an incoming call has been obtained from directory number translation table 111, that call is extended to RT 50 in the particular assigned timeslot OEi --illustratively indicated in FIG. 2 as timeslot 46. Timeslot 46 is herein referred to as a "feeder" timeslot inasmuch as link 45, on which that timeslot is carried, extends between the central office and the first external cross-connection point in the local loop plant.
The local loop associated with the TNi and OEi in question is comprised, in a logical sense, of the aforementioned feeder timeslot 46 in combination with a particular "distribution" timeslot 66 carried on link 65 and with a particular one of service ports 79j and its associated one of the drop pairs 91j. In order for the cross-connection between feeder timeslot 46 and distribution timeslot 66 to be effectuated, an entry must be provided in a cross-connection table within RT controller 56 of RT 50, that entry associating timeslots 46 and 66 with one another, i.e., "cross-connecting" them. This cross-connection table is shown in FIG. 5, with identifiers for timeslots 46 and 66 being symbolically represented as TS46 and TS66, respectively. The cross-connection is illustratively implemented by timeslot interchange 55 within RT 50 operating under the control of RT controller 56. Finally, a cross-connection table (not shown) within DT controller 76 of DT 70 associates timeslot 66 with the appropriate one of service ports 79j, enabling a timeslot interchange 75 within DT 70 to distribute calls carried in timeslot 66 to the appropriate drop pair.
It will be appreciated from the foregoing that the use of table-driven timeslot interchanges in the cross-connection elements takes the place of the manual operations of placing manual cross-connections in passive cross-connection elements as in FIG. 1. Indeed, the cross-connection tables in the RT and DT may be remotely administered, like table 111, from a central provisioning system 80 over signaling links 85 extending to every RT and DT in the local loop plant. The central administration of the cross-connection tables is advantageous in that many of the data errors that arise as a consequence of manual operations and human data entry are avoided. In particular, it is true, on the one hand, that current telephone company practice is to continue to make LFACS data entries in their present form--the only difference being that the data in the F1, F2, . . . pair fields of the LFACS records refer to feeder and distribution timeslots rather than to wire pairs. On the other hand, however, since the LFACS records and cross-connection table entries are jointly administrable, synchronization between them, i.e., accuracy of the LFACS database, is guaranteed, at least in theory.
Problems remain, however. For example, there still remains the need for a loop assignment database to keep track of the cross-connections thus made. Additionally, the remote administration of the cross-connections brings with it the need to administer an added infrastructure--most notably signaling links 85. Moreover, manual data entry is still required when, for example, the capabilities and/or capacities of the RTs and DTs are changed, e.g., to add additional service ports to a DT by installing new service port cards.
It is to the amelioration of the above and other problems that the present invention is directed. In particular, a communications access arrangement--illustratively a telephone local loop plant-embodying the principles of the invention is shown in FIG. 3. This arrangement is similar to that shown in FIG. 2 except that in the hierarchy of access network nodes, including RTs 350 and 390 and DTs 370 and 395, various new capabilities are provided in, for example, the central office switch, the RTs and DTs, and the provisioning system.
In accordance with the invention, cross-connections between switching office 310 and any particular one of the endpoints OEi served by the switch and associated with service ports 379i of DT 370, i=1 . . . M, those ports serving as "downstream" ports for DT 370, are set up on a call-by-call basis to establish a connection between them based on information generated from within the access network itself. The invention thus avoids the prior art's need for a centralized loop assignment database/provisioning system to keep track of manually made cross-connections or to carry out centrally controlled cross-connection administration. Indeed, it may be noted in this regard that there are no links interconnecting provisioning system 380 with any of the RTs or DTs.
In this embodiment, more particularly, communications between telephone central office 310 and OEi are established using the invention set forth in our above-referenced U.S. patent application by routing an identification of that endpoint through the access network via the use of previously stored routing information, that information identifying, at telephone central office 310 and at each of a plurality of packet switching elements within the access network, a particular downstream link over which the endpoint can ultimately be reached. The aforementioned packet switching elements are illustratively co-located within the cross-connection elements within the access network nodes, i.e., RT 350 and DT 370, themselves, and the routing information stored therein is used to packet switch messages from telephone central office 310 to DT 370. Responsive to receipt of such messages, DT 370 thereupon initiates the setting up of the connection through the cross-connection elements to carry the call in a manner to be described--illustratively beginning from service port 379i and working its way back through DT 370 and RT 350 back to telephone central office 310.
The foregoing may be more fully understood by considering four basic scenarios: installation of DTs and RTs, customer service provisioning, and two call-placing scenarios--call termination and call origination.
We begin by considering the installation of a new DT--illustratively, DT 370--in the local loop plant. The process begins with the engineering of the installation of the DT by telephone company planners using a conventional engineering system (not shown). After the DT has been set in place, its identity and street address are entered into central provisioning system 380 from the engineering system. The physical link between DT 370 and its associated RT 350--illustratively FITL link 365--is then established.
In accordance with the invention, each DT in the local loop plant of FIG. 3 has implemented within it a capability that has been used in other contexts, that being the ability to report information about itself (self-report information) to an upstream entity--in this case the RT to which it is connected--so that, overall, the network is provided with the ability to "learn" its own topology. It is via this mechanism that the aforementioned routing information is generated and stored automatically in the access network, as is described in detail hereinbelow.
More particularly, the aforementioned reporting upstream by a DT curs when the DT is first connected into the network. It also occurs whenever subsequent changes are made to a DT's configuration, e.g., the addition of a new service port card. Specifically, then, DT controller 376 within DT 370 reports to RT controller 356 within RT 350 when the DT is installed. The information originated from within DT 370 and reported to the RT includes, inter alia, an identification of the particular one of the terminating access network nodes in which it is included, i.e., DT 370 itself; its equipment configuration; its currently provisioned capabilities; and information about each of its service ports. The communication between DT controller 376 and RT controller 356 is carried out over a particular channel of link 365 which is set aside for the communication of administrative messages between the RT and DT. That channel-referred to as the "embedded operations channel" or EOC--is carried in a particular timeslot on link 365. As shown in the FIG., the EOC, and call processing signaling channel, or CPSC, and timeslot assignment signaling channel, or TASC, discussed below, are carried from DT controller 376 to RT controller 356 via signaling path 372, timeslot interchange (TSI) 375, link 365, timeslot interchange (TSI) 355 and signaling path 354.
The arrangement of FIG. 3 uses neither the notion of a switch termination point OEi nor of a timeslot OEi within the logical local loop. Rather, each telephone number TNi is associated directly with a local loop endpoint OEi which is the physical connection point of a particular one of the service ports of a particular DT to the associated drop pair. The representation of each local loop endpoint OEi --the OEi identifier--illustratively has the format shown in FIG. 6. An initial portion of the OEi identifier identifies the DT of which it is a part, that portion being denominated IDDT. The terminal portion of the OEi identifier is a port number which differentiates the various local loop endpoints PEi within a particular DT from one another. Upon receiving the OEi identifiers from DT 370, RT 350 adds entries to a DT termination table maintained within RT controller 356. As shown in FIG. 7, that table relates the IDDT of each DT to which RT 350 is connected to the link which extends from RT 350 to connect it to the DT in question, that link having been identified by RT 350 at the time that DT 370 first reported its presence to RT 350. Thus as shown explicitly in FIG. 7, this DT termination table includes an entry relating DT 370 to link 365, with identifiers for those two entities being symbolically represented as DT370 and L365, respectively.
Each RT has self-reporting capabilities similar to those described above for DTs. Thus at the time that RT 350 had been installed, a similar series of operations had been carried out, including the engineering of its installation; the entry of its identity and street address to provisioning system 380; the establishment of a physical link 345 between RT 350 and central office switch 311, that link being, as before, a T1 line group; and the reporting of similar self-report information upstream from RT controller 356 into central office switch 311 over the EOC which interconnects RT 350 and central office 310. In particular, the EOC, CPSC and TASC extend from RT controller 356 to switch 311 via signal path 352, timeslot interchange 355, and link 345.
The information reported by RT 350 to central office switch 311 at the time of the former's installation--and at subsequent times, as needed--includes an identification of itself; its equipment configuration; its currently provisioned capabilities; and information about that portion of the network which is downstream of the reporting RT. For present purposes, it suffices to focus on the latter information. Specifically, among the pieces of information reported from RT 350 to central office switch 311 are all of the OEi identifiers from all of the DTs connected to RT 350, such as DT 370. Thus upon a) the installation of DT 370, b) its interconnection with RT 350, and c) its reporting of its OEi identifiers, all as described above, RT 350 reports those OEi identifiers from DT 370 all the way back upstream to central office switch 311. That latter, in turn, adds entries to an RT termination table maintained within switch controller 3110 of central office switch 311. As shown in FIG. 8, that table relates the IDDT of each OEi identifier reported to switch 311 to a feeder link and its associated EOC and CPSC/TASC extending from the switch which interconnects the switch with the RT in question. Thus as shown explicitly in FIG. 8, the RT termination table includes an entry relating DT 370 to link 345, identifiers for those two entities being symbolically represented as DT370 and L345, respectively. The information in the aforementioned tables thus identifies for each endpoint OEi a path, or route, through the access network from the switching office to the DT in which it is included.
Central office switch 311, in turn, reports all of the downstream OEi identifiers that are reported to it to central provisioning system 380. Advantageously, there is thus stored and ready in the provisioning system an identification of the service ports, and thus of the endpoints, of the newly installed DT 370.
Specifically, when a telephone subscriber speaks to a telephone company business office representative requesting service at some particular location, the representative accesses provisioning system 380 to assign a local loop endpoint OEi that already serves that street address. Failing this, the provisioning system 380 assigns any available OEi in the DT nearest the street address. (Alternatively, OEi could be chosen by the craftperson installing the customer premises equipment, and entered into the system by the craftperson, either directly or through the provisioning system.) Having identified an appropriate local loop endpoint OEi, the representative assigns telephone number TNi to the subscriber using conventional procedures and enters a service order which a) describes the type of service(s) and features desired by the customer, b) associates TNi with the local loop endpoint OEi, and c) if the OEi is newly assigned to the address in question, arranges for the connection of a drop from that endpoint to the customer premises. The provisioning system thereupon downloads the service and feature information, as well as the TNi and the OEi identifier, into central office switch 311 via link 85. The latter, in particular, is loaded into a directory number translation table 3111 shown both in FIG. 3 and in FIG. 9. The specific example shown in FIG. 9 is an entry relating a particular TNi, 555-1234, with service port #1 of DT 370, that service port having an OEi identifier symbolically represented as DT370-1.
Central office switch 311 is, at this point, ready to provide service for calls to and from the provisioned telephone number. And in marked contradistinction to the prior art, that readiness to provide service has been provided without there having to have been a) any craftpersons deployed to any cross-connection points within the access network, nor b) any configuration of, or any information loaded into, any portion of the access network by any human operator or even by the provisioning system. Indeed, the invention renders unnecessary a need for either the COSMOS or the LFACS database systems or their equivalents, as well as any control links from the provisioning system to the RTs or DTs, and at the same time substantially eliminates the possibility of continued human error in the assignment process.
Looking at a typical call termination scenario, central office switch 311 responds to receipt of a call placed to telephone number 555-1234, i.e., responds to the placing of that call, by finding from table 3111 the corresponding OEi identifier--in this case DT370-1. Using the IDDT portion of the OEi identifier--namely DT 370--the switch identifies link 345, from the table of FIG. 8, as being the appropriate link onto which it should place a signaling message indicating that an incoming call has been received for the local loop endpoint OEi identified as DT370-1. This and other call-processing-related messages are transmitted within a call processing signaling channel, or CPSC, that is carried within a particular timeslot on link 365, that timeslot also carrying the timeslot assignment signaling channel, or TASC, discussed below.
The message from central office switch 311 to RT 350 is thereupon packet switched within RT 350. That is, the endpoint identifier is used to determine how the message is to be forwarded on. In particular, RT controller 356 receives the CPSC via TSI 355 and, acting as a packet switching element, uses the OEi identifier DT370-1 to identify from its DT termination table (FIG. 7) that link 365 is the link on which messages destined for DT 370 should be placed. The message, more specifically, is transmitted out through TSI 355 onto the CPSC of link 365. The message to DT 370 is thereupon similarly packet switched within DT 370. In particular, DT controller 376 receives the CPSC via TSI 375 and, acting as a packet switching element, examines the OEi identifier DT370-1 included in the message and determines that the message is destined, in this case, for service port 3791. The latter is thereby caused to extend a ringing signal over drop pair 911, which is the drop pair connected to it.
It will be observed that, at this point, there is no voice or other call connection between central office switch 311 and service port 3791. However, the connection can now be set up. In particular, when the called subscriber answers the phone, service port 3791 detects the off-hook condition of the telephone set. DT 370 thereupon causes its fiber channel unit 371 serving as an "upstream" port of DT 370 to negotiate with one of the fiber channel units 359 serving as "downstream" ports of RT 350 for the assignment of a timeslot on that link to service port 379i, the negotiation being over the TASC on link 365. A segment of a virtual local loop connection has thus been established between the RT and the DT. Responsive to the initiation of the timeslot negotiation, trunk unit 351 in the RT serving as an "upstream" port thereof is controlled to similarly negotiate with digital carrier line unit 3115 within central office switch 311 for the assignment of a timeslot on link 345 to service port 379i, thereby establishing a segment of the virtual local loop connection between the RT and the central office switch. An identification of the endpoint identified as DT 370-1 as having been the endpoint for which this call connection is being made is carried up to the switch as part of the timeslot negotiation procedure so that central office switch 311 is able to determine which of its endpoints is establishing a connection to it. Finally, a "make connection" message initiated by switch 311 and conveyed all the way down to DT 370 causes the assigned timeslots to be cross-connected by the cross-connection elements, i.e., TSI 355 and 375. A call connection between switch 311 and service port 3791 thus having been established on a call-by-call basis, the parties can begin to speak to one another. (The above-mentioned negotiation for timeslots, and the subsequent management and use thereof as the call progresses and various possible error conditions and how they can be handled, may advantageously be substantially similar to analogous functionalities carried out in prior art "concentrating" DLC systems and FITL systems and thus need not be described in detail herein. Reference may be made in this regard, for example, to the portions of Bellcore Technical Reference TR-TSY-000008 and of Bellcore Technical Reference TR-NWt-000303 describing concentrating systems, those references being hereby incorporated by reference.)
We consider, now, a call origination scenario. Specifically, when a subscriber begins to place a call by going off hook, DT 370 addresses a signaling message to central office switch 311 over the CPSCs of links 365 and 345, requesting the provision of dial tone for a particular OEi. (Since each network element has a well-defined signaling route upstream to the switch, the routing of this message can proceed straightforwardly in a conventional fashion.) Timeslots to carry the call are thereupon negotiated first over the TASCs between switch 311 and RT 350 and then between RT 350 and DT 370 in the manner described above, again establishing a connection on a call-by-call basis. The negotiated timeslots are thereupon interconnected and the switch supplies dial tone thereover. As the customer thereupon dials digits for the outgoing call, DT 370 forwards them over the CPSC to switch 311 which, in turn, processes the call in conventional manner.
Scenarios for tearing down the connections established as described above, as well as other call processing scenarios, such as the steps to be taken when the called telephone number is "busy," will be apparent and/or readily able to be devised by those skilled in the art and need not be described herein.
The foregoing is merely illustrative and many variations are possible. Some of those variations will now be described:
Although the illustrative embodiment includes only a single RT between the central office switch and the DT, it will be appreciated that, in analogy to the arrangement shown in FIG. 1, there may be any desired number of RTs between the switch and the DT, each such RT having an appropriate routing table similar to those shown in FIGS. 7 and 8.
In the illustrative embodiment, the packet switching elements via which messages are routed are co-located with the cross-connection elements within respective access network nodes. In other embodiments, however, a totally separate packet switching network, with its own separate access network nodes (wherein the routing information would be stored) and its own set of links within the access network, could be used.
In yet other embodiments, the routing information may be contained within the same access network nodes that contain the cross-connection elements, as in the disclosed embodiment, but the routing information is used to set up the connections segment-by-segment directly, starting from the switching office. In such other embodiments, specifically, the switch uses its routing table to identify an appropriate downstream link over which it should communicate with a downstream RT to negotiate a timeslot to set up a first segment of the connection to be established. Using either inband signaling over the channel thus established or out-of-band signaling over the CPSC, the switch forwards the OEi identifier over the RT in question. The latter then a) uses its routing table to identify an appropriate downstream link over which it should communicate with a downstream RT or DT to negotiate a timeslot to set up a second segment of the connection to be established, and b) then cross-connects its incoming and outgoing timeslots. This process is repeated until a complete connection to the endpoint has been established. Note that, here again, cross-connections between the switching office and any particular endpoint are set up on a call-by-call basis to establish a connection.
The TN to OE translation function may be distributed among the RTs and/or DTs in the access network. In this configuration, a) the initial downstream incoming call signaling from the switch to the RTs and DTs is broadcast downstream to RTs and/or DTs, and b) individual ones of RTs and/or DTs contain information similar to that of FIG. 9 which maps a TN to a particular endpoint. From this point on, the signaling proceeds in a manner similar to that described above.
The setting up the cross-connections on a call-by-call basis as described herein is not limited to so-called "switched services" wherein calls of relatively short duration are the norm. Rather, it is equally applicable to calls of extremely long duration, effectively implementing the equivalent of a so-called "special services" circuit.
Various transmission elements could be added to either the switch-to-RT or RT-to-DT links. An example would be to provide an access network where the group of five T1 lines are themselves multiplexed together and routed over a SONET ring of higher bandwidth. The characteristic aspect of such arrangements is that the intervening transmission elements do not perform DS0-level re-arrangement, nor do they participate in the signaling and DSO bandwidth assignment functions that are characteristic of the access network nodes described herein.
The present illustrative embodiment shows a single RT between the switch and the DT. It will be appreciated that the path between the switch and the DT can include any desired number of RTs, including none, meaning that it is possible to link a DT directly to the switch. Moreover, it is possible for some subscriber premises to be connected directly to an RT while that same RT is connected to other subscriber premises via DTs, per the illustrative embodiment.
A network element could be multiply connected to two or more access network nodes that are upstream of it, rather than just one, as shown herein. Such an approach creates multiple message routes and also multiple connection paths between the switch and the DT. Any of a number of commonly known selection criteria can be used to select the paths used for (a) the EOC, (b) the CPSC/TASC, and (c) connections between each pair of access network nodes. Given the selection of a particular path for the EOC and CPSC/TASC, assignment and connection operations similar to those described above may be performed.
In the present illustrative embodiment, the "channels" and "timeslots" are presumed to be fixed-bit-rate entities. In other embodiments, however, they could be variable-bit-rate entities.
The above discussion presents the channel negotiation process--by which the various channels between the switch and the OEi are dynamically assigned--as one in which the channels are assigned within each successive link in serial fashion. Those skilled in the art will appreciate, however, that many different negotiation processes could be developed, including processes that perform several of the described operations concurrently, thereby providing lower call set-up times.
Additional variations involve more complex service and customer premises equipment (CPE) arrangements. For example, multiple TNs could be associated with a single OEi, thereby facilitating the implementation of so-called "teenage" lines and "party" lines. Also, so-called "intelligent" CPE can be designed to report their TNs upstream within the access network in a manner similar to that used in present-day cellular telephone networks. Upon receipt of such a TN report, the access network can dynamically reassign the TN of the CPE to the local OEi where the user is then located, thereby allowing a subscriber to receive calls placed to his/her phone number wherever he/she happens to be at the moment.
A simplified RT design is possible wherein the RT does not have any message routing responsibility. Rather, this responsibility is assumed by the switch. In this variation, an RT is transparent to the EOCs and CPSC/TASCs passing through it between DTs and the switch. To accommodate such an approach, the switch would be arranged to associate all subtending DTs with their respective RT(s), even though they do not share a common EOC between the RT and the switch. Connections are then established by issuing setup requests to the RT over its TASC and to the DT over its own TASC. This can be seen to be logically equivalent to the illustrative embodiment described.
The links interconnecting the various network access nodes are disclosed here as being time-division-multiplexer links. Those links, however, could, attentively, be links which support packet or cell multiplexing techniques, in which instance each "channel" is defined by a virtual channel identifier. More particularly, these links could be links which support the so-called asynchronous transfer mode, or ATM.
It will thus be appreciated that those skilled in the art will be able to devise numerous arrangements which, although not explicitly shown or described herein, embody the principles of the invention and are thus within its spirit and scope.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4479196 *||Nov 15, 1982||Oct 23, 1984||At&T Bell Laboratories||Hyperedge entity-relationship data base systems|
|US4646229 *||Nov 15, 1982||Feb 24, 1987||At&T Bell Laboratories||Time-ordered data base|
|US4751697 *||Sep 5, 1986||Jun 14, 1988||American Telephone And Telegraph Company, At&T Bell Laboratories||Distributed packet switching sytem|
|US4821259 *||Sep 5, 1986||Apr 11, 1989||American Telephone And Telegraph Company, At&T Bell Laboratories||Control information communication arrangement for a distributed control switching system|
|US5014266 *||Jun 26, 1990||May 7, 1991||At&T Bell Laboratories||Circuit switching system for interconnecting logical links between packet switching networks|
|1||*||Bellcore Technical Reference TR NWT 000303, Issue 2, Dec. 1992, Integrated Digital Loop Carrier System Generic Requirements, Objectives, and Interface .|
|2||*||Bellcore Technical Reference TR TSY 000008, Issue 2, Aug. 1987, Digital Interface Between the SLC96 Digital Loop Carrier and a Local Digital Switch .|
|3||Bellcore Technical Reference TR-NWT-000303, Issue 2, Dec. 1992, "Integrated Digital Loop Carrier System Generic Requirements, Objectives, and Interface".|
|4||Bellcore Technical Reference TR-TSY-000008, Issue 2, Aug. 1987, "Digital Interface Between the SLC96 Digital Loop Carrier and a Local Digital Switch".|
|5||*||ETSI Work Item No.: DE/SPS 3003.2, Version: 7, Apr. 28, 1993, Signalling Protocols and Switching V interfaces at the digital Local Exchange (LE) V5.2 interface for the support of Access Network (AN) .|
|6||ETSI Work Item No.: DE/SPS-3003.2, Version: 7, Apr. 28, 1993, "Signalling Protocols and Switching V interfaces at the digital Local Exchange (LE) V5.2 interface for the support of Access Network (AN)".|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US5475735 *||Dec 2, 1993||Dec 12, 1995||Motorola, Inc.||Method of providing wireless local loop operation with local mobility for a subscribed unit|
|US5499289 *||Dec 6, 1994||Mar 12, 1996||At&T Corp.||Systems, methods and articles of manufacture for performing distributed telecommunications|
|US5666349 *||Aug 28, 1996||Sep 9, 1997||Siemens Aktiengesellschaft||Method for controlling components of a communication system|
|US5687224 *||Jul 26, 1995||Nov 11, 1997||Alley, Jr.; Willard Kent||Telecommunications circuit provisioning and administration system|
|US5781537 *||Jul 7, 1995||Jul 14, 1998||International Business Machines Corporation||Setting up, taking down and maintaining connections in a communications network|
|US5805593 *||Sep 26, 1995||Sep 8, 1998||At&T Corp||Routing method for setting up a service between an origination node and a destination node in a connection-communications network|
|US5822420 *||Aug 30, 1996||Oct 13, 1998||Digital Technics, Inc.||Signaling protocol for multilink access network-local exchange interfaces|
|US5907548 *||Dec 28, 1995||May 25, 1999||Lucent Technologies Inc.||Telephone network local access using data messaging|
|US6026144 *||Feb 23, 1996||Feb 15, 2000||Lucent Technologies Inc.||Method for improving the administration of the telephone local loop plant|
|US6031837 *||May 5, 1997||Feb 29, 2000||Fujitsu Limited||Method for forming multiple bidirectional connections for use in asynchronous transfer mode switching device|
|US6061807 *||Jun 27, 1997||May 9, 2000||International Business Machines Corporation||Methods systems and computer products for error recovery of endpoint nodes|
|US6075784 *||Jul 9, 1998||Jun 13, 2000||Jetstream Communications, Inc.||System and method for communicating voice and data over a local packet network|
|US6167041 *||Mar 17, 1998||Dec 26, 2000||Afanador; J. Abraham||Switch with flexible link list manager for handling ATM and STM traffic|
|US6175623 *||Mar 18, 1999||Jan 16, 2001||Nokia Telecommunications Oy||Procedure for the management of a subscriber database in a telephone exchange|
|US6252955 *||Feb 3, 2000||Jun 26, 2001||Nokia Networks Oy||Procedure for subscriber addressing in a cascaded V5 interface|
|US6324384 *||Jun 19, 1997||Nov 27, 2001||Fujitsu Limited||Call processing method, subscriber unit, and access control apparatus operated in wireless local loop system|
|US6542599 *||Apr 7, 1999||Apr 1, 2003||Fujitsu Limited||Subscriber system transmission apparatus with line concentrating capability|
|US6606679 *||Nov 28, 2001||Aug 12, 2003||Intel Corporation||Software transparent system and method for peer-to-peer message routing|
|US6639913 *||May 19, 1999||Oct 28, 2003||Paradyne Corporation||System and method for communicating voice and data over a local packet network|
|US6684251 *||May 25, 2000||Jan 27, 2004||Sprint Communications Company, L.P.||Dynamic connection set-up in a communication network|
|US7002991 *||Aug 11, 2000||Feb 21, 2006||Lucent Technologies Inc.||Method and apparatus for provisioning distribution channels in a communications network|
|US7720944||Oct 30, 2007||May 18, 2010||Invensys Systems, Inc.||Process control system with networked digital data processors and a virtual machine environment|
|US7739361||Oct 30, 2007||Jun 15, 2010||Thibault Richard L||Methods for remote process control with networked digital data processors and a virtual machine environment|
|US7761923||Mar 1, 2005||Jul 20, 2010||Invensys Systems, Inc.||Process control methods and apparatus for intrusion detection, protection and network hardening|
|US7860857||Mar 30, 2007||Dec 28, 2010||Invensys Systems, Inc.||Digital data processing apparatus and methods for improving plant performance|
|US7882197||Oct 30, 2007||Feb 1, 2011||Invensys Systems, Inc.||Control system methods that transfer control apparatus information over IP networks in web page-less transfers|
|US7890927||Oct 8, 2008||Feb 15, 2011||Invensys Systems, Inc.||Apparatus and method for configuring and editing a control system with live data|
|US7899070||Oct 30, 2007||Mar 1, 2011||Invensys Systems, Inc.||Control system apparatus with change updates|
|US7979488||Oct 30, 2007||Jul 12, 2011||Invensys Systems, Inc.||Control system methods using value-based transfers|
|US7984420||Nov 5, 2008||Jul 19, 2011||Invensys Systems, Inc.||Control systems and methods with composite blocks|
|US8023500||Oct 30, 2007||Sep 20, 2011||Invensys Systems, Inc.||Methods for process control with change updates|
|US8028272||Nov 5, 2008||Sep 27, 2011||Invensys Systems, Inc.||Control system configurator and methods with edit selection|
|US8028275||Nov 5, 2008||Sep 27, 2011||Invensys Systems, Inc.||Control systems and methods with smart blocks|
|US8060222||Nov 5, 2008||Nov 15, 2011||Invensys Systems, Inc.||Control system configurator and methods with object characteristic swapping|
|US8081584||Oct 30, 2007||Dec 20, 2011||Invensys Systems, Inc.||Control system apparatus and systems using value-based transfers|
|US8090452||Jul 20, 2007||Jan 3, 2012||Invensys Systems, Inc.||Methods and apparatus for control using control devices that provide a virtual machine environment and that communicate via an IP network|
|US8127060||May 29, 2009||Feb 28, 2012||Invensys Systems, Inc||Methods and apparatus for control configuration with control objects that are fieldbus protocol-aware|
|US8225271||Nov 6, 2008||Jul 17, 2012||Invensys Systems, Inc.||Apparatus for control systems with objects that are associated with live data|
|US8229579||Nov 5, 2008||Jul 24, 2012||Invensys Systems, Inc.||Control systems and methods with versioning|
|US8368640||Feb 14, 2006||Feb 5, 2013||Invensys Systems, Inc.||Process control configuration system with connection validation and configuration|
|US8463964||Oct 14, 2010||Jun 11, 2013||Invensys Systems, Inc.||Methods and apparatus for control configuration with enhanced change-tracking|
|US8594814||Jun 19, 2009||Nov 26, 2013||Invensys Systems, Inc.||Systems and methods for immersive interaction with actual and/or simulated facilities for process, environmental and industrial control|
|US20040230643 *||Jan 26, 2004||Nov 18, 2004||Invensys Systems, Inc.||Methods and apparatus for remote process control|
|US20060206860 *||Feb 14, 2006||Sep 14, 2006||Invensys Systems, Inc.||Process control configuration system with connection validation and configuration|
|US20060206866 *||May 15, 2006||Sep 14, 2006||Invensys Systems, Inc.||Methods and apparatus for control configuration using live data|
|US20060294579 *||Mar 1, 2005||Dec 28, 2006||Invensys Systems, Inc.||Process control methods and apparatus for intrusion detection, protection and network hardening|
|US20070233664 *||Mar 30, 2007||Oct 4, 2007||Invensys Systems, Inc.||Digital data processing apparatus and methods for improving plant performance|
|US20080052386 *||Jul 20, 2007||Feb 28, 2008||Invensys Systems, Inc.||Methods and apparatus for control using control devices that provide a virtual machine environment and that communicate via an ip network|
|US20080052632 *||Oct 30, 2007||Feb 28, 2008||Invensys Systems, Inc.||Methods for remote process control with networked digital data processors and a virtual machine environment|
|US20080134215 *||Oct 30, 2007||Jun 5, 2008||Invensys Systems, Inc.||Methods for process control with change updates|
|US20080148170 *||Oct 30, 2007||Jun 19, 2008||Invensys Systems, Inc.||Control system apparatus with change updates|
|US20080222276 *||Oct 30, 2007||Sep 11, 2008||Invensys Systems, Inc.||Control system apparatus and systems based thereon that transfer control apparatus information over IP networks in web page-less transfers|
|US20090094326 *||Dec 12, 2008||Apr 9, 2009||Invensys Systems, Inc.||Control system methods and apparatus with services|
|US20090125128 *||Nov 5, 2008||May 14, 2009||Invensys Systems, Inc.||Control systems and methods with versioning|
|US20090125129 *||Nov 5, 2008||May 14, 2009||Invensys Systems, Inc.||Control system configurator and methods with edit selection|
|US20090125130 *||Oct 8, 2008||May 14, 2009||Invensys Systems, Inc.||Control system editor and methods with live data|
|US20090125131 *||Nov 5, 2008||May 14, 2009||Invensys Systems, Inc.||Control systems and methods with composite blocks|
|US20090132996 *||Nov 6, 2008||May 21, 2009||Invensys Systems, Inc.||Apparatus for control systems with objects that are associated with live data|
|US20090164031 *||Dec 12, 2008||Jun 25, 2009||Invensys Systems, Inc.||Methods and apparatus for control using control devices that communicate via an ip network|
|US20100011127 *||Jul 8, 2009||Jan 14, 2010||Invensys Systems, Inc.||Methods and apparatus for control using control devices that provide a virtual machine environment and that communicate via an ip network|
|US20100076604 *||Oct 22, 2009||Mar 25, 2010||Invensys Systems, Inc.||Method and apparatus for control using control devices that provide a virtual machine environment and that communicate via an ip network|
|US20100223593 *||Mar 4, 2010||Sep 2, 2010||Invensys Systems, Inc.||Methods and apparatus for control configuration with object hierarchy, versioning, change records, object comparison, and other aspects|
|US20110093098 *||Oct 14, 2010||Apr 21, 2011||Invensys Systems, Inc.||Methods and apparatus for control configuration with enhanced change-tracking|
|US20140244851 *||Feb 21, 2014||Aug 28, 2014||Zentera Systems, Inc.||Secure virtual network platform for enterprise hybrid cloud computing environments|
|WO1997035443A2 *||Mar 18, 1997||Sep 25, 1997||Telefonaktiebolaget Lm Ericsson (Publ)||System and method for providing services to subscriber stations connected to an access network|
|WO1997035443A3 *||Mar 18, 1997||Feb 19, 1998||System and method for providing services to subscriber stations connected to an access network|
|WO1999065179A2 *||May 19, 1999||Dec 16, 1999||Jetstream Communications, Inc.||System and method for communicating voice and data over a local packet network|
|WO1999065179A3 *||May 19, 1999||Feb 3, 2000||Jetstream Communications Inc||System and method for communicating voice and data over a local packet network|
|U.S. Classification||370/352, 379/272, 370/386, 370/420, 340/2.1, 379/269|
|International Classification||H04M3/00, H04Q3/66, H04Q3/545, H04Q3/58|
|Aug 27, 1993||AS||Assignment|
Owner name: AMERICAN TELEPHONE AND TELGRAPH COMPANY, NEW YORK
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DAUGHERTY, THOMAS H.;DEBRULER, DENNIS L.;GREENBERG, DANIEL S.;AND OTHERS;REEL/FRAME:006685/0415;SIGNING DATES FROM 19930811 TO 19930824
|Jun 29, 1998||FPAY||Fee payment|
Year of fee payment: 4
|Jun 27, 2002||FPAY||Fee payment|
Year of fee payment: 8
|Jul 7, 2006||FPAY||Fee payment|
Year of fee payment: 12
|Mar 7, 2013||AS||Assignment|
Effective date: 20130130
Free format text: SECURITY INTEREST;ASSIGNOR:ALCATEL-LUCENT USA INC.;REEL/FRAME:030510/0627
Owner name: CREDIT SUISSE AG, NEW YORK
|Oct 9, 2014||AS||Assignment|
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033950/0001
Effective date: 20140819