WO1999062235A1 - Trunk management system for telecommunications - Google Patents
Trunk management system for telecommunications Download PDFInfo
- Publication number
- WO1999062235A1 WO1999062235A1 PCT/AU1999/000414 AU9900414W WO9962235A1 WO 1999062235 A1 WO1999062235 A1 WO 1999062235A1 AU 9900414 W AU9900414 W AU 9900414W WO 9962235 A1 WO9962235 A1 WO 9962235A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- station
- service
- packet
- address
- rsc
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
Definitions
- TITLE TRUNK MANAGEMENT SYSTEM FOR TELECOMMUNICATIONS
- This invention relates to systems for managing telecommunications links and, more particularly, to apparatus, systems and methods for remotely controlling or monitoring the stations of a communications link using digital service channel(s) provided by the link itself. While the invention is particularly suited for use in terrestrial digital microwave systems, it is also applicable to digital trunk cable and even to some satellite communications systems.
- the digital communications links with which this invention is concerned are typically high capacity and heavily multiplexed but are able to 'break-out' limited capacity service channel(s) without having to demultiplex the 'payload traffic.
- Such sophisticated telecommunications links are herein called 'trunks', irrespective of the character, source and destination of the traffic.
- the service channel or channels are used for link management, monitoring and servicing and normally comprise at least one full-duplex 64kb/s synchronous communications channel in each direction that is accessible by each station in the trunk.
- the service channel is usually accessed at each station by demodulating a carrier signal to the base or frame level where the inter-frame bits that comprise the service channels can be read.
- each trunk will comprise at least three stations; namely, two end stations and at least one intermediate relay or repeater station, the end station which is connected to a network control centre or a trunk controller being called the 'head' while the other end station is called the 'tail'.
- An intermediate station is said to be 'down' or 'down-link' from the head and 'up' or 'up-link' from the tail.
- the manufacturers or vendors of equipment for telecommunications trunks employ their own proprietary point-to-point protocols on the trunk service channels so that vendor's equipment at a trunk controller can monitor and/or control the individual stations in a trunk using proprietary synchronous transport protocols.
- each manufacturer or vendor offers its own proprietary system with its own specialised hardware that is incompatible with the monitoring and control systems of other vendors. There is even inconsistency as to where and how the clock signals are generated and transported in the service channel.
- This invention is based on the realisation that it is possible to efficiently implement Internet Protocol (IP) in a multi-drop manner on a typical digital service channel of a telecommunications trunk, despite its limited capacity and normal synchronous party- line character. Hitherto, this has been impractical or impossible because IP requires each packet to be fully buffered at each intermediate station before it can be forwarded on the service channel. If long IP packets are passed from station to station on what is effectively a party-line in this way, delays can be expected quickly compound to such a degree that effective communications on a trunk service channel is impractical. As far as the applicant is aware, no prior art system has enabled an IP host to communicate using IP with the stations of a trunk via the digital service channel.
- IP Internet Protocol
- the present invention comprises a telecommunications trunk - or service channel - capable of transporting IP packets so that communication between stations, and between stations and the controller, can take place in a transparent manner using IP with such higher level IP-compatible protocols (for example, UDP, TCP, HTTP or SNMP) as desired.
- the invention also comprises means for effecting the transport of IP packets on the service channel of a telecommunications trunk in such a manner as to permit both the trunk controller and individual stations of the trunk to operate using IP.
- This desirable result may be achieved by treating the stations of a trunk collectively as a single IP subnet by employing the head station as a transparent router to encapsulate and re-address incoming IP packets in the form of 'service packets' that have short non-IP addresses corresponding to the trunk stations, so that each station can read the address of a service packet using low-level processes without needing to to buffer the whole packet.
- Each station preferably has a computer-based remote site controller (RSC) that runs IP and extracts the IP packets from incoming service packets addressed to it, and processes the received IP packets appropriately.
- RSC remote site controller
- it is desirable that each RSC is able to generate it own IP packets containing data for other stations or for the wider network, and to encapsulate each in a service packet that is addressed appropriately for transport on the service channel.
- each service packet has a short station address located at a fixed position at or near the start of the service packet, the station address can be read after only a small portion of the packet has been received at an RSC, so the packet can be immediately forwarded (unless addressed to the RSC in question).
- the head station RSC needs to routinely receive the whole of each incoming packet, whether it is an IP packet from the control centre or a service packet from the service channel.
- the head station needs to buffer each incoming IP packet while its address is read and the service packet vehicle is constructed. It also needs to buffer the whole of each service packet to allow the IP packet therein to be recovered and forwarded to the controller, or dealt with within the head RSC if addressed to it. Since the controller and the head RSC normally will be on a common LAN, the speed of exchange of IP packets between the controller and the head RSC need not be of concern.
- the head station RSC acts as a transparent IP router for the controller or a host at the control centre acting like an IP server with no knowledge of or concern with the structure of service packets or the protocol by which they are transported on the service channel.
- the trunk stations appear as normal IP addresses, which are accessible from anywhere on the Internet, subject to appropriate firewall and other security measures imposed by the control centre LAN.
- Known proprietary network management systems eg, Cabletron's SPECTRUM, Hewlett Packard's OPEN VIEW, Sun's SUNET MANAGER, or IBM's NET VIEW
- a simple and effective system of assigning Internet addresses to the stations of a trunk is to ensure that the IP addresses for the stations on a trunk differ only in only their least significant address digit(s) or byte(s) and to ensure that the stations are numbered in ascending order down the chain, with the head station assigned the lowest station address.
- the lowest and highest possible station addresses - say, 00 and FF - are generally reserved as network and broadcast addresses ]
- the head station RSC simply copies the last byte of the IP address into the appropriate place in a service packet header formed to carry the IP packet. If the incoming IP packet is addressed to the head station itself, its RSC immediately processes the packet within its own IP regime.
- Every station on the service channel runs IP to process IP packets that it receives and to generate IP packets for transmission to other stations or to the controller for action or further routing.
- the RSC at each station encases each IP packet it generates within a service packet that it creates, addresses and puts on the service channel.
- Those service packets intended for other stations on the service channel preferably use the last byte of the destination station's IP address to address the service packet in the manner already indicated.
- Service packets containing IP packets that are not intended for another station are, by default, given the service channel address of the head station.
- Any station receiving a service packet with its own address takes the whole service packet off the service channel, extracts the IP packet and handles it using the appropriate higher level protocols (eg, SNMP/UDP) in the IP environment of its RSC.
- the appropriate higher level protocols eg, SNMP/UDP
- most of the incoming service packets with its address will contain IP packets having addresses outside the service channel network and these IP packets will therefore be passed on to the controller for appropriate routing or processing.
- low-level routing means can be employed by the RSC at each station to determine whether a self-generated service packet should be placed on the up-link or on the down-link by comparing the service address of the packet with that of the station at which it is generated. Incoming packets from other stations on the service channel can thus be assumed to be intended for down-line stations with higher addresses and are forwarded accordingly. It is preferred that each RSC employs software daisy-chaining techniques to couple to the service channel to avoid delays due to differences in receiver and transmitter data rates or clock phase between RSCs.
- Each station RSC can communicate with on-site station elements such as RS232 devices, SCADA data recording systems, switches, intruder alarms, battery monitors, performance monitoring systems, digital and analogue l/Os (input/outputs) and, particularly, transceiver and data transport alarm events.
- a computer terminal might be connected to an RSC by a technician using a standard serial or parallel interface for communication with another technician at another RSC (or anywhere on the larger network).
- communication with legacy vendor- specific devices at the station and control centre can be handled in the same manner, if necessary by encapsulating vendor-format packets in IP packets.
- IP packets containing vendor-specific data received by the controller can be directed to the vendor's management or control devices. In this way, legacy and new monitoring/management equipment can operate side by side using the one service channel while having the benefits of IP at the control centre and each RSC.
- a simple way of doing this is to regard all alarms occurring within a few seconds of another alarm as being members of a bunch or storm of alarms that are likely to have the same primary cause.
- This permits the use of a default mode for reporting alarms from a station in which only the first alarm of a bunch or storm is reported to the centre (with, perhaps, an indication of the number of alarms in the associated bunch or storm).
- This default procedure can reduce the load on the service channel manyfold in alarm situations where faults are intermittent or propagated along the stations of a trunk.
- all alarms in a storm recorded by any station can be transmitted to the centre for analysis.
- MIBs management information bases
- SNMP simple network management protocol
- Figure 1 is a diagram showing three stations of a generic digital microwave communications trunk of known form.
- Figure 2 is a schematic illustration of a system of the present invention the allowing a remote site controller at any trunk station to communicate with a communications control centre as if it is part of an IP network.
- Figure 3 is a diagram illustrating the manner in which vendor packets, IP packets and service channel packets are handled in the chosen example
- Figure 4 is a more detailed block diagram of a trunk station employed in the network of Figure 2.
- the digital microwave communications system 10 of Figure 1 is employed as a trunk connection between one telephone region 12 and another14 and represents systems in common use.
- System 10 comprises a chain of repeater stations 16R arranged between a head station 16H in region 12 and a tail station 16T in region 14, only one repeater station being depicted for the sake of clarity.
- Head station 16H includes a call- traffic input down-line multiplexer 18 that multiplexes incoming call/data lines 20 into a stream 22 of T1 frames (for example); an output down-line multiplexer 24 that adds a 64kb/s down-line service channel 26D to stream 22 by utilising inter-frame gaps; a down-line microwave modulator and transmitter 28 that generates microwave beam 29; an up-line microwave receiver and demodulator 30 that takes incoming radio traffic from region 14 on microwave beam 32, demodulates it and passes the demodulated signal to an up-line input demultiplexer 34 which generates a stream of frames 36 and breaks out the up-line (return) service channel 26U; an up-line output demultiplexer 38 that generates an outgoing group of call/data lines 40 to region 12; a service channel interface unit 42H that is connected to receive alarm signals from and send control signals to I/O (input/output) devices (eg data-loggers and controllers) 44. Since this is the head station, the service channel input 26
- Repeater station 16 has a down-line receiver 50 that converts beam 29 into a demodulated signal that is fed to an input down-line demultiplexer 52, which generates frame stream 22, breaks out down-line service channel 26D and feds it to service interface 42R. Outgoing down-line service channel 26D is then added to frame stream 22 by down-line mulitplexer 24H, which feeds the combined multiplexed signal to down-line transmitter 28H that regenerates beam 29.
- Up-going beam 32 from region 14 is received at repeater station 16R by up-line receiver/demodulator 30R and the demodulated signal is passed to a demultiplexer 34R that breaks out up-line service channel 26U and passes up-line frame stream 36 to a multiplexer 38R that recombines frame-stream 36 with service channel 26U and feeds it to an output up-line modulator/transmitter 54, which regenerates up-beam 32.
- repeater station 16R includes a service channel interface unit 42R through which down-line service channel 26D and up-line service channel 26U are fed, interface also having I/O circuits 44R connected to monitor and control elements of the repeater station 16R.
- tail station 16T is essentially a mirror image of head station 16H.
- An input receiver demodulator 50T receives incoming beam 29 and its demodulated output is fed to demultiplexer 52T that generates frame-stream 22 and breaks out down-line service channel 26D.
- Frame stream 22 is demultiplexed to line level and output as a group of lines 60 into region 14, while a group of incoming lines 62 from region 14 is combined into up-going frame stream 36 by multiplexer 34T.
- Up-line output multiplexer 38R then combines service channel 26U with frame-stream 36 and feed the combined signal to up-line output modulator ⁇ ransmitter 54T to generate up- going microwave beam 32.
- tail station 16T is fitted with a service channel interface unit 42T that takes down-going service channel 26D as an input and generates up-going service channel 26U as an output.
- Interface 42T is again connected to I/O circuits 44R that are connected to monitor and/or control the operation of the station.
- Station interface units 42, controller 46 and often I/O units 44 are usually vendor- specific so that they are expensive and usually cannot be modified to take new inputs or effect new controls.
- the packet protocols and coding employed are proprietary and designed to allow the data from stations to be collected in a polling (point-to-point) sequence. They are therefore poorly adapted for (and in many cases not capable of) use in communicating from one station to the next, or even from one station to the controller. Generally such communication depends upon the availability of additional party-line type service channels capable of transmitting voice or modem signals.
- FIG. 2 is a functional schematic representation of an IP compatible trunk management system 50 formed in accordance with this invention wherein the control centre 52 comprises a local Ethernet LAN 54, with operator terminals 56, that communicates via an Internet host system server 58 with remote site controllers (RSCs) at each trunk station using the trunk service channel.
- host 58 is connected via the Internet 60 to RSC 62 at the head station (not indicated) of the trunk (not indicated).
- Head RSC 62 is connected by the trunk service channel 64 to all stations, including in particular remote station 66 having remote RSC 68 which is connected to monitor various parameters at station 66.
- RSC 68 is supplied with vendor-format data from a legacy vendor interface 70.
- device 70 may be a generic SCADA or data-logger device.
- RSC 68 is connected to receive other direct inputs, including analogue signals for battery voltages 71 and temperatures 72, and digital signals from security devices 73 and transceiver alarm lines 74.
- a field terminal 75 may also be connected to RSC 68 (via a RS232 connection, for example) so that it can be used by a service technician to communicate with any other trunk station, with control centre 52, or even with any other suitable device on the Internet.
- all data inputs are time-stamped - especially the transceiver alarms 74 where timing is critical to diagnosis.
- Such alarms may be triggered by faulty fibres and cables or their connections, by lost frames due to multi-path fading in microwave trunks or by system control faults, and their time stamping can be effected with the minimum of delay using RSC 68 and a GPS-derived clock 76 that is also connected directly to the RSC 68.
- transceiver alarm storms are identified and appropriately recorded so that the first alarm of each storm can be accessed by the RSC 68 for transmission to the control centre upon the receipt by the RSC of the appropriate interrogation IP packet from the control centre. This can save a great deal of unnecessary traffic on the service channel, as well as facilitate alarm analysis.
- Figure 3 is a diagram illustrating the manner in which the transmission of information from the control centre 52 to the remote trunk station 66 in Figure 2 is handled in various digital packets.
- the transmission of data from station 66 to centre 52 typically involves the reverse procedure, except for a variation in the addressing of service packets, which will be explained below.
- legacy vendor's equipment is installed at the control centre 52 and in station 66. If such legacy equipment is not present the additional steps of handling the vendor's packets or data at each end of the process are not required.
- Non-IP format data from vendor control equipment (46 in Figure 1 ) at centre 52 ( Figure 2) intended for vendor equipment (79 in Figure 2 or 42 in Figure 1 ) is packetised at centre 52 to generate a vendor packet 80 that is encapsulated in an IP packet 82 by host server 58.
- IP packet 82 is addressed to RSC 68 using normal IP procedures and routed to the head RSC 62.
- all stations on the trunk are given consecutive addresses ascending from that of the head station to that of the tail station, the station number being indicated by the last significant byte of the IP address. In Figure 3, this byte is indicated at 84 in packet 82.
- Head RSC 62 receives packet 82 and examines its IP address.
- RSC 62 Since the packet 82 is not addressed to its own IP address, RSC 62 adds a head and tail to packet 82 to create a service packet 85 in HDLC format that 'encapsulates' IP packet 82. RSC 62 copies address byte 84 of IP packet 82 into the beginning of the head of service packet 85 where it is located either at the start of the packet or at a fixed number of bytes from the start of the packet. This copied byte now forms the address 86 of the service packet 85 and is the address of remote RSC 68. Head RSC then places service packet 85 on the down-line of the service channel 64 (see Figure 2) on which it is fed past each station RSC inturn.
- address 86 is examined and the packet 85 is immediately passed down-line without any significant delay in each successive station, until station 66 with RSC 68 is reached. Since address 86 matches that of RSC 68, the service packet 85 is taken off the service line and the head and tail of packet 85 are removed by RSC 68 to 'unpack' IP packet 82. RSC 68 then processes packet 82 in an IP environment. It is likely that packet 82 will have a flag that is set to indicate that the pay-load data contained by the packet is intended for the vendor-specific device 70 at station 66. Accordingly, vendor data packet 80 is delivered to device 70 for processing in accordance with the vendor's programs. Though the service channel 64 is not an IP environment, IP packets can be conveyed transparently to and from the IP environment of host 58 and the IP environment of the RSC in any trunk station, with minimal delay and complication.
- FIG 4 illustrates in diagrammatic form the microwave station 66 of Figure 2 and its RSC 68 which includes a VMEBus board 90 with a CPU 92 and various I/O ports, including an IP Ethernet port 94 that can optionally be connected to controller 58 if RSC 68 is reconfigured as the head RSC.
- Station 66 includes up-side and down-side microwave transceiver units 100 and 102.
- Up-side transceiver unit 100 includes microwave transmitter 104 and receiver 106
- down-side transceiver unit 102 includes receiver 108 and transmitter 110.
- Down service channel 112 connects receiver 106 to transmitter 110 via RSC 68
- up service channel 114 connects receiver 108 to transmitter 104 via the RSC. Normal serial RS232 connections could be used.
- a monitoring and control unit 116 in up-side transceiver unit 100 is connected to an I/O port 118 on RSC 68, while a similar monitoring and control unit 120 in downside transceiver unit 102 is connected to another I/O port 122 on RSC 68.
- the main payload traffic connections between transceiver units 100 and 102 are not illustrated.
- the number, type and use of the I/O ports 118 and 122 depends on the manner in which the station's trunk management systems monitoring and control units 116 and 120 and radio status and control electronics are implemented. For the purpose of this example, it may be assumed that the various inputs alarms and controls illustrated or
- Substitute Sheet mentioned in respect of station 66 in Figure 2 can be incorporated in monitor units 116 and 120, including GPS clock inputs.
- an MIB may be implemented on a second computer (not shown) in station 66 and connected to the RSC 68 through the I/O port 118 and/or 122 to allow communication of SNMP packets between the second computer and the RSC 68, all analogue and digital inputs, alarms and clocks being handled by the second computer.
- an MIB can be implemented within the RSC 68.
- HDLC service packets arriving on down-link service channel 112 from up-side receiver 106 are fed via a short FIFO down-buffer 124 and a down by-pass switch 128 to down-side transmitter 110.
- FIFO 124 is connected to CPU 92 via port 126 and line 123 so that the address of a service packet therein can be read. Packets emerging from FIFO 124 on line 112 can be received by port 125 via line 127.
- HDLC packets arriving on up-channel 114 are fed via a FIFO 130 (which is connected to CPU port 131 via line 129) and via up bypass switch 132 to up-side transmitter 104; and, packets emerging from FIFO 130 on line 114 can be received by input port 134 via line 136.
- Down bypass switch 128 is controlled by output port 138 and line 139 so that either line 112 is connected to transmitter 110 or an output line 140 from an output port 142 on card 90 is connected to transmitter 110.
- up bypass switch 132 is controlled via line 133 by output port 144 of card 90 so the either line 114 or an output line 146 from an output port 148 is connected to up-side transmitter 104.
- a service packet arriving at FIFO 124 is automatically stepped through the buffer. At the appropriate time and position in buffer 124 the service address byte of the packet header in the buffer is read by control port 126. If the service packet has the address of this particular station 66, by-pass switch 128 connects down transmitter 110 to output line 140 and the packet is taken off line 112 (as it emerges from FIFO 124) by port 125 for processing by CPU 92 in the manner described above with respect to Figure 3. If the packet is not addressed to this station but bypass switch 128 is open, the packet is also taken off line 112 by line 127 and
- bypass switch 128 was in the process of transmitting a service packet itself to transmitter 110. As soon as such transmission is completed , switch 128 can be returned to its normal by-pass position (as shown).
- RSC 68 when RSC 68 has a service packet to transmit, it will have the choice of passing it to uplink transmitter 104 or downlink transmitter 110. The choice is made by comparing the destination address of the service packet with that of its own station. If the packet address is higher, it should be placed on the downlink transmitter 110; if lower, it should be placed on the uplink transmitter 104.
- Use of the switches 128 and 132, together with the ability to buffer packets waiting for transmission allows two or more RSCs to simultaneously transmit without interference.
- each RSC is symmetric with respect to the downstream and upstream; that is each RSC can receive service packets addressed to it on either the downstream and upstream and that each RSC can transmit service packets addressed to any other station on either the downstream and the upstream.
- This symmetry is useful, for example, where the usual tail station is used as the head station, or where a repeater station is to be used as a head station or a back-to-back head station.
- each RSC includes means tor communicating via an IP LAN to a controller using IP packets.
- HDLC SYNC Flag 7E. One Byte addressing (source & destination). Two byte length field.
- the Local interface wants to send an IP packet out on the service channel network interface (as determined by IP routing tables): a) it reserves descriptors pointing to the packet and its encapsulating service packet header, b) if the least significant byte of the destination IP address is less than the RSCs station address the service packet needs to be sent on the upstream port c) if more then downstream d) if same then return back to IP layer (local echo) e) if 255 then network broadcast so send both upstream & downstream.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA002333325A CA2333325A1 (en) | 1998-05-26 | 1999-05-26 | Trunk management system for telecommunications |
AU41237/99A AU747498B2 (en) | 1998-05-26 | 1999-05-26 | Trunk management system for telecommunications |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AUPP3723 | 1998-05-26 | ||
AUPP3723A AUPP372398A0 (en) | 1998-05-26 | 1998-05-26 | Microwave network management systems |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1999062235A1 true WO1999062235A1 (en) | 1999-12-02 |
Family
ID=3807970
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/AU1999/000414 WO1999062235A1 (en) | 1998-05-26 | 1999-05-26 | Trunk management system for telecommunications |
Country Status (3)
Country | Link |
---|---|
AU (1) | AUPP372398A0 (en) |
CA (1) | CA2333325A1 (en) |
WO (1) | WO1999062235A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001045335A1 (en) * | 1999-12-02 | 2001-06-21 | Nokia Corporation | Call routing in a telecommunication system |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5130974A (en) * | 1989-03-30 | 1992-07-14 | Nec Corporation | Multidrop control network commonly used for carrying network management signals and topology reconfiguration signals |
WO1998010541A1 (en) * | 1996-09-09 | 1998-03-12 | Hybrid Networks, Inc. | Broadband communication system for high-speed internet access |
EP0902576A1 (en) * | 1997-08-27 | 1999-03-17 | DSC Telecom L.P. | Multiple network configuration with local and remote network redundancy by dual media redirect |
US5903559A (en) * | 1996-12-20 | 1999-05-11 | Nec Usa, Inc. | Method for internet protocol switching over fast ATM cell transport |
-
1998
- 1998-05-26 AU AUPP3723A patent/AUPP372398A0/en not_active Abandoned
-
1999
- 1999-05-26 CA CA002333325A patent/CA2333325A1/en not_active Abandoned
- 1999-05-26 WO PCT/AU1999/000414 patent/WO1999062235A1/en active IP Right Grant
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5130974A (en) * | 1989-03-30 | 1992-07-14 | Nec Corporation | Multidrop control network commonly used for carrying network management signals and topology reconfiguration signals |
WO1998010541A1 (en) * | 1996-09-09 | 1998-03-12 | Hybrid Networks, Inc. | Broadband communication system for high-speed internet access |
US5903559A (en) * | 1996-12-20 | 1999-05-11 | Nec Usa, Inc. | Method for internet protocol switching over fast ATM cell transport |
EP0902576A1 (en) * | 1997-08-27 | 1999-03-17 | DSC Telecom L.P. | Multiple network configuration with local and remote network redundancy by dual media redirect |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001045335A1 (en) * | 1999-12-02 | 2001-06-21 | Nokia Corporation | Call routing in a telecommunication system |
US7606261B2 (en) | 1999-12-02 | 2009-10-20 | Nokia Corporation | Call routing in a telecommunication system |
Also Published As
Publication number | Publication date |
---|---|
CA2333325A1 (en) | 1999-12-02 |
AUPP372398A0 (en) | 1998-06-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6697870B1 (en) | Method and apparatus for real-time protocol analysis using an auto-throttling front end process | |
EP0753950A1 (en) | Adaptive repeater system | |
US8365255B1 (en) | Configuration file download enforcement | |
CA2326894A1 (en) | Voice and data apparatus comprising a selective tapping digital signal processing resource | |
US20020049862A1 (en) | Method and apparatus for providing optical internetworking to wide area networks, metropolitan area networks, and local area networks using modular components | |
EP1113626A1 (en) | Interface link layer device to build a distributed network | |
JPH10276196A (en) | Communication monitor | |
US8040887B2 (en) | Encapsulation of E1-type frames under ethernet | |
US7519072B2 (en) | Transmission system including media converter for concentrated VDSL apparatus | |
US20040141499A1 (en) | Optical communication network using a code division multiplexing method | |
EP1246413B1 (en) | Method, equipment and system for signaling in a network including ethernet | |
EP0899915B1 (en) | Apparatus and method for selectively supplying data packets between media domains in a network repeater | |
JP2001168915A (en) | Ip packet transfer system | |
EP1633087B1 (en) | Repeater apparatus for supporting a plurality of protocols, and a method for controlling proctocol conversion in the repeater apparatus | |
AU747498B2 (en) | Trunk management system for telecommunications | |
WO1999062235A1 (en) | Trunk management system for telecommunications | |
CN115720302A (en) | Communication control method, system, device and storage medium | |
Cisco | Interface Commands (show pas caim - tx-queue-limit) | |
Cisco | Interface Commands | |
Cisco | Interface Commands | |
Cisco | Interface Commands | |
Cisco | Interface Commands | |
Cisco | Interface Commands | |
Cisco | Tunneling of Asynchronous Security Protocols | |
Cisco | Tunneling of Asynchronous Security Protocols |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 41237/99 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 09700657 Country of ref document: US |
|
ENP | Entry into the national phase |
Ref document number: 2333325 Country of ref document: CA |
|
NENP | Non-entry into the national phase |
Ref country code: KR |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
122 | Ep: pct application non-entry in european phase | ||
NENP | Non-entry into the national phase |
Ref country code: CA |
|
WWG | Wipo information: grant in national office |
Ref document number: 41237/99 Country of ref document: AU |