Source: http://www.google.com/patents/US20030137982?dq=6,308,317
Timestamp: 2014-10-26 00:35:53
Document Index: 570013755

Matched Legal Cases: ['art 600', 'art 600', 'art 600', 'art 700', 'art 700', 'art 700']

Patent US20030137982 - Filtering and forwarding frames at an optical network node - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsAn optical line terminal (OLT) monitors and controls communications with a plurality of optical nodes (ONs), such as optical network units (ONUs) and/or optical network terminators (ONTs), within a passive optical network (PON), such as, but not exclusively, an Ethernet-based passive optical node (EPON)....http://www.google.com/patents/US20030137982?utm_source=gb-gplus-sharePatent US20030137982 - Filtering and forwarding frames at an optical network nodeAdvanced Patent SearchPublication numberUS20030137982 A1Publication typeApplicationApplication numberUS 10/353,053Publication dateJul 24, 2003Filing dateJan 29, 2003Priority dateDec 14, 2001Also published asDE60232820D1, EP1466444A2, EP1466444A4, EP1466444B1, US7245621, US7349394, US7411980, US20030117998, US20030152389, WO2003052946A2, WO2003052946A3Publication number10353053, 353053, US 2003/0137982 A1, US 2003/137982 A1, US 20030137982 A1, US 20030137982A1, US 2003137982 A1, US 2003137982A1, US-A1-20030137982, US-A1-2003137982, US2003/0137982A1, US2003/137982A1, US20030137982 A1, US20030137982A1, US2003137982 A1, US2003137982A1InventorsDolors Sala, John Limb, Ajay GummallaOriginal AssigneeBroadcom Corporation.Export CitationBiBTeX, EndNote, RefManReferenced by (10), Classifications (7), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetFiltering and forwarding frames at an optical network nodeUS 20030137982 A1Abstract An optical line terminal (OLT) monitors and controls communications with a plurality of optical nodes (ONs), such as optical network units (ONUs) and/or optical network terminators (ONTs), within a passive optical network (PON), such as, but not exclusively, an Ethernet-based passive optical node (EPON). A tagging mechanism is implemented to identify an origin ON that introduces a frame into the PON segment linking the origin ON with the OLT. The origin ON produces a PON tag to associate its identifier (ON_ID) to the frame. The PON tag facilitates filtering and forwarding operations, and enables the physical layer interface (PHY) to the PON segment to emulate a point-to-point and/or shared communications link. The PON tag allows a MAC control layer to create virtual ports to traffic incoming and outgoing optical signals, and supply the virtual ports to a forwarding entity for frame filtering and forwarding. The PON tag also allows an OLT and ON to track the origination and/or destination of a frame within the PON segment, and accept or reject the frame based on the contents of the PON tag. Images(12) Claims(53)
[0095] It should be understood that a multicast or broadcast frame can be sent on a P2P path to each member of the multicast or broadcast group, or on a shared path to all optical nodes (e.g., ON 106) operating on the shared path. If sent to all optical nodes operating on a shared path, the optical nodes that are members of the multicast group would accept the frame, and the non-members would reject the frame. Similarly, it should be understood that a unicast frame can be sent on a P2P path to the designated optical node (e.g., ON 106), or on a shared path to all optical nodes (e.g., ON 106) operating on the shared path. If sent to all optical nodes operating on a shared path, the designated recipient of the unicast would accept the frame, and all other optical nodes on the shared path would reject the frame. [0096] At step 515, the forwarding-tagged frame is queued according to the incoming port (i.e., physical port or logical port) of the physical interface that received the frame. In an embodiment, OLT 102 matches the incoming port to the frame upon receipt. In another embodiment, the incoming port is detected or extracted from one or more fields within the frame (e.g., from PON tag control information field 224). In another embodiment, OLT 102 has separate and parallel processing paths for all available ports, and queues the frames accordingly. [0097] At step 518, the queues (designating a respective incoming port) are emptied to pass the upstream frames to a forwarding entity. In an embodiment based on logical ports, the upstream frames are passed with the forwarding tags. In an embodiment based on multiple physical ports, the upstream frames are passed over designated physical interfaces with the forwarding entity. After the upstream frames are passed to the forwarding entity, the control flow ends as indicated by step 595. [0098] Referring, now, to FIG. 6, flowchart 600 represents the general operational flow for processing and/or updating a PON tag for transmission from an OLT (e.g., OLT 102), according to an embodiment of the present invention. More specifically, flowchart 600 shows an example of a control flow for processing and/or updating a PON tag after being passed to a forwarding entity associated with an OLT (e.g., OLT 102). [0099] The control flow of flowchart 600 begins at step 601 and passes immediately to step 603. At step 603, the forwarding entity receives a frame. In an embodiment based on logical ports, the frame includes the forwarding tag. In an embodiment based on multiple physical ports, the forwarding entity notes the incoming port that received the frame, since the frames are queued by incoming port. [0100] At step 606, the forwarding entity determines the destination port(s) for the frame. In an embodiment, the forwarding entity uses the destination address (i.e., DA field 206) to query a look-up or forwarding table to determine the destination port(s). The table can be programmable to learn destination addresses and corresponding port(s). [0101] At step 609, the forwarding entity considers the frame's incoming port type (i.e., a traditional physical interface or a PON-enabled physical interface). As discussed, this information is noted at step 603 from the queue. In an embodiment, the forwarding entity learns that a specific queue is associated with a specific port type. In another embodiment, a tag is appended to the frame to designate the incoming port prior to being handed to the forwarding entity, and the forwarding entity learns the port type. Alternatively, a tag can be appended, prior to delivering the frame to the forwarding entity, to designate the incoming port type. In another embodiment, a learning table is queried and/or updated to determine the port type from the incoming port. As would be apparent to one skilled in the relevant art(s), other variants, methodologies, or techniques can be used to permit the forwarding entity to become aware of the incoming port or port type. [0102] If the incoming port is PON-enabled, at step 612, the incoming port is included as a destination port, regardless of whether it had been determined to be a destination port at step 606. As a result, a PON-tagged frame is always reflected back to the origin ON 106. In an embodiment, all upstream traffic is reflected back on all PON-enabled ports. In another embodiment, upstream traffic is only reflected back on a PON-enabled port configured for shared distributions. [0103] On the other hand, if the incoming port is a traditional port, the control flow passes immediately to step 615. Therefore, since a forwarding entity conventionally does not transmit signals back on an incoming port, the frame is not returned to the incoming port if it is not included in the destination port(s). [0104] At step 615, the frame is queued according to its destination port(s). The queues are subsequently emptied for further processing. If a destination port is a PON-enabled port, the OLT (e.g., OLT 102) verifies or prepares a PON tag for downstream transmission. In the downstream, the PON tag is referred to as the downstream PON tag (or Dtag). [0105] Referring back to FIG. 3b, a representative PON tag includes mode field 304 denoted as �shared� or �P2P,� and TID field 306 specifying an origin ON_ID. If mode field 304 is set to �P2P,� the forwarding entity determines the PON segment destination and OLT 102 modifies, if necessary, TID field 306 to specify the �destination� ON_ID. The modified tag �(P2P, destination ON_ID)� becomes the downstream PON tag that is passed with the frame to its downstream destination. As discussed above if the frame is externally generated or from an unknown source, the PON tag would already read �(P2P, destination ON_ID).� Therefore, no modification should be required. [0106] On the other hand if mode field 304 is set to �shared,� the forwarding entity determines the group membership for the multicast or broadcast, but OLT 102 does not modify the TID field 306. The downstream PON tag is the same as the upstream PON tag, namely �(shared, origin ON_ID)� if the frame is PON-originated or �(shared, universal ON_ID)� if externally generated or from an unknown source. [0107] If a destination port is a traditional port or if the frame is being sent to a higher layer application or MAC client of the OLT (e.g., OLT 102), the PON tag is removed. Moreover if at any step a PON-tagged frame is passed to a traditional device (e.g., bridge, router, etc.) that is not PON-aware, the PON tag is eliminated. After the frame has been passed to its destination port(s), the control flow ends as indicated by step 695. [0108] The present invention, therefore, provides a PON-aware forwarding entity having the capability to interact with a PON segment as if the segment is one of the known segment types, namely shared, P2P, or both. Unlike a conventional forwarding entity, the PON-aware forwarding entity of the present invention does not assume all peers have seen an upstream frame. A conventional forwarding entity will not hand a frame to a destination port if it is the incoming port that received the frame. However, in the present invention, a PON-aware forwarding entity reflects back all PON-tagged frames received over a shared path. [0109] VI. Processing Downstream PON Tag by an Optical Node [0110] As discussed, FIG. 4 describes an embodiment for producing and/or updating a PON tag for upstream transmissions. FIGS. 5-6 describe embodiments for processing and/or updating a PON tag at an OLT (e.g., OLT 102). Referring, now, to FIG. 7, flowchart 700 represents the general operational flow of the reception process at an optical node (e.g., ON 106) according to an embodiment of the present invention. More specifically, flowchart 700 shows an example of a control flow for processing and/or updating a PON tag upon delivery at an optical node (e.g., ON 106). [0111] The control flow of flowchart 700 begins at step 701 and passes immediately to step 703. At step 703, an optical node (e.g., ON 106) receives a frame (e.g., frame 200 c, 200 d, 200 e, etc.) from a downstream channel. At step 706, the optical node (e.g., ON 106) detects or reads a PON tag appended to the frame. As discussed, in an embodiment, PON tag type field 222 designates the frame as being a PON-tagged frame. [0112] At step 709, the optical node (e.g., ON 106) determines whether the frame has been distributed in P2P or shared mode. In an embodiment, mode field 304 is processed to determine whether the frame is designated as being in P2P or shared mode. If P2P mode is determined, the control flow passes to step 712. Otherwise, the control flow passes to step 715 for processing shared distributions. [0113] At step 712, the optical node (e.g., ON 106) determines whether it is the intended recipient of the frame. As discussed above, a PON-tagged frame sent downstream in P2P mode includes mode field 304 and TID field 306 values reading �(P2P, destination ON_ID). If the destination ON_ID specified in TID field 306 does not match the ON_ID of the recipient optical node (e.g., ON 106), the optical node is not the intended recipient. As such, the frame is discarded at step 718. Otherwise, the frame is accepted at step 721. [0114] Shared mode distributions are processed at step 715. When executed, step 715 enables a recipient optical node (e.g., ON 106) to determine whether it originated a PON-tagged frame (e.g., frame 200 c, 200 d, 200 e, etc.) received in the downstream. As discussed above, a PON-tagged frame sent on a shared downstream includes mode field 304 and TID field 306 values reading �(shared, origin ON_ID)� for PON-originated frames and �(shared, universal ON_ID)� for externally generated or unknown sourced frames. Processing TID field 306, the optical node (e.g., ON 106) determines if its ON_ID(s) matches and hence, whether it is the origin optical node (i.e., it originated the PON-tagged frame). If the recipient optical node is the origin optical node, the frame is rejected at step 718. Otherwise, it is accepted, at step 721, because the frame is determined to be produced by a peer optical node (e.g., ON 106). [0115] This process is effective for supporting reflect-back operations of a PON-enabled OLT (e.g., OLT 102). The reflect-back operations permit one or more peer optical nodes (e.g., ON 106) to remain aware of signals transmitted upstream to the OLT (e.g., OLT 102), especially on a shared communications path. Additionally, reflecting-back permits a peer optical node on a shared path to receive the frame if an intended destination is one of the subscriber end users of the peer optical node. Conversely, traditional OLT-forwarding entities do not return the frame to the shared path peers because it assumes that the peers have already seen the frame. [0116] If the frame (received from a shared or P2P path) is accepted, then at step 724, the PON tag is deactivated or removed from the frame and sent to a higher layer application or MAC client for further processing. Afterwards, the control flow ends as indicated by step 795. [0117] As described above, TID field 306 designates the ON_ID as being a single node identifier. In other words, TID field 306 specifies an identifier for a single optical element of system 100 (namely, one of ON 106). It should be understood that the single node designation of TID field 306 has been described by way of example. In embodiments of the present invention, the contents or value of TID field 306 is easily extendable to support a multi-node designation. If, for example, a single ON 106 belongs to one or more groups of ON 106, a membership identifier is specified for each group. The single ON 106, therefore, retains a list of membership identifiers for each of these groups. As a frame is processed as described herein, a membership identifier is included in TID field 306 to specify source and/or destination identifiers for a multicast according to the embodiments herein described. For example, ON 106 is enabled to perform a check rule to either select a membership identifier to produce a PON tag prior to sending a frame, or to verify a membership identifier to process a PON tag prior to accepting or rejecting a frame. Similarly, OLT 102 is enabled to perform a check rule to select a membership identifier while processing or producing a downstream PON tag, as discussed above. [0118] VII. System Architecture for ONU and OLT [0119]FIG. 8 illustrates an embodiment of ON 106 that can be used to implement the present invention as described with reference to FIGS. 1-7. ON 106 includes a physical layer interface (PHY) 802, media access control (MAC) layer 804, and MAC control layer 806. In an embodiment, PHY 802, MAC 804, and MAC control 806 are configured to comply with the specifications of IEEE standard 802.3 and/or 803.3ah. [0120] PHY 802 serves to receive and transmit signals (e.g., voice, data, video, etc.) among the subscriber end-users (shown as MAC client 808), as discussed above with reference to FIG. 1. As discussed above, ON 106 utilizes one or more physical or logical ports to communicate with OLT 102 over the PON segment. Additionally, one or more physical or logical ports are used to communicate with its end users (MAC client 808). PHY 802 also supports full duplex communications (e.g., voice, data, video, control messages) with OLT 102. Hence, PHY 802 is configurable to support electronic, electromagnetic, optical signals, and/or the like. PHY 802 modulates signals to be transmitted as bursts, and demodulates signals that it receives. In an embodiment, PHY 802 performs error checking on a received signal and/or discard the signal if errors are found. [0121] Signals from PHY 802 are passed to MAC 804 for Ethernet protocol processing. It should be understood that the above reference to Ethernet protocol processing is provided by way of example. Hence, in alternate embodiments, MAC 804 performs protocol processing in compliance with other types of communication protocols governing multimedia distribution networks. [0122] MAC control 806 receives frames from MAC 804 and integrates the tagging mechanism of the present invention. In an embodiment, MAC 804 takes a frame coming from MAC client 808, and appends or inserts a PON tag (e.g., PON tag type field 222 and PON tag control information field 224). The resulting PON tagged-frame (e.g., frame 200 c, 200 d, 200 e, etc.) is queued for delivery to PHY 802. [0123] During registration with OLT 102, ON 106 receives instructions (e.g., ON_ID and/or membership identifier values to use in the PON tag) to establish and format the ports. At this time, ON 106 can request additional ports. [0124]FIG. 9 illustrates an OLT 102 according to an embodiment of the present invention. OLT 102 includes a physical layer interface (PHY) 902, media access control (MAC) layer 904, MAC control layer 906, a forwarding entity 908, and a forwarding table 914. In an embodiment, PHY 902, MAC 904, and MAC control 906 are configured to comply with the requirements of IEEE standard 802.3, and forwarding entity 908 is configured to conform to IEEE standard 802.1D, with additional functionality according to the present invention. [0125] PHY 902 supports full duplex communications (e.g., voice, data, video, control messages) with ON 106 (or ONU 800). Accordingly, PHY 902 transmits and receives optical signals via the PON segment. PHY 902 demodulates the signals to decompress and/or extract voice, data, video, requests, other control messages, and/or the like. In an embodiment, PHY 902 performs error checking, if required. If errors are detected, the burst is discarded. In another embodiment, the burst is flagged and the error is corrected at MAC 904. [0126] Therefore, MAC 904 performs Ethernet protocol processing. As discussed above, it should be understood that the above reference to Ethernet protocol processing is provided by way of example. Hence, in alternate embodiments, MAC 904 performs protocol processing in compliance with other types of communication protocols governing multimedia distribution networks. [0127] MAC control 906 processes, updates, and/or constructs the PON tag of the present invention. In an embodiment, MAC control 906 reads or extracts the PON tag received from PHY 902 and produced by the origin ON 106, and prepares a forwarding tag, as described above. If MAC control 906 receives a frame lacking a PON tag (e.g., an external frame), a null PON tag is constructed, as described above. The null PON tag is appended to the frame as its forwarding tag. The frame (with forwarding tag) is queued according to the incoming port that received the frame from the upstream. [0128] Forwarding entity 908 (such as a bridge, router, etc.) reads destination address (e.g., DA field 206) and queries forwarding table 914 to determine the destination port(s) for each frame. Forwarding table 914 includes disposition instructions for forwarding information (e.g., frame 200 a, 200 b, 200 c, 200 d, etc.) delivered to OLT 102. The disposition instructions include, but are not limited to, a destination port (physical or logical) corresponding to a destination or source address, port mirror requirements, frame handling requirements, prioritization, multicast group membership, and/or like features. In an embodiment, forwarding table 914 is programmable to learn port associations with MAC or PON addresses, and/or forwarding table 914 is responsive to periodic or on-demand updates, regarding the port associations, from an operator interface, software application, or another control system. In an embodiment, forwarding table 914 is programmable to store a PON tag with the associated frame. [0129] Upon receipt of disposition instructions, forwarding entity 908 filters and queues the frames to be forwarded to the destination port(s). Forwarding entity 908 is a PON-aware forwarding entity, and therefore, forwarding entity 908 forwards back a frame to its incoming port if the incoming port is a PON port. Additionally, forwarding entity 908 includes a plurality of physical or logical ports for downstream transmissions to ON 106. One or more shared physical or logical ports support shared communications, and multiple physical or logical ports support P2P communications. Each ON 106 has a designated physical or logical port for P2P communications. Thus, in an embodiment OLT 102 includes a single physical port to the PON segment, multiple logical ports configured for P2P and/or shared paths, and another physical port to backbone 110. In another embodiment, OLT 102 includes multiple physical ports with or without logical ports. [0130] After the frames have been filtered into the appropriate destination port, the frames (with their appended forwarding PON tags) are forwarded to MAC control 906. MAC control 906 updates or prepares a downstream PON tag (or Dtag) for each frame. The frame then passes to MAC 904 for further formatting or protocol processing, and to PHY 902 to be transmitted to its downstream destination. [0131] VIII. Exemplary System Implementation [0132] FIGS. 1-9 are conceptual illustrations allowing an easy explanation of the present invention. It should be understood that embodiments of the present invention could be implemented in hardware, firmware, software, or a combination thereof. In such an embodiment, the various components and steps would be implemented in hardware, firmware, and/or software to perform the functions of the present invention. That is, the same piece of hardware, firmware, or module of software could perform one or more of the illustrated blocks (i.e., components or steps). [0133] Additionally, the present invention can be implemented in one or more computer systems capable of carrying out the functionality described herein. Referring to FIG. 10, an example computer system 1000 useful in implementing various components or steps of the present invention is shown. Various embodiments of the invention are described in terms of this example computer system 1000. After reading this description, it will become apparent to one skilled in the relevant art(s) how to implement the invention using other computer systems and/or computer architectures. [0134] The computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 can be a special purpose or a general purpose digital signal processor. Processor 1004 is connected to a communication infrastructure 1006 (e.g., a communications bus, crossover bar, or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a one skilled in the relevant art(s) how to implement the invention using other computer systems and/or computer architectures. [0135] Computer system 1000 also includes a main memory 1008, preferably random access memory (RAM), and can also include a secondary memory 1010. The secondary memory 1010 can include, for example, a hard disk drive 1012 and/or a removable storage drive 1014, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 1014 reads from and/or writes to a removable storage unit 1018 in a well-known manner. Removable storage unit 1018 represents a floppy disk, magnetic tape, optical disk, etc. As will be appreciated, the removable storage unit 1018 includes a computer usable storage medium having stored therein computer software (e.g., programs or other instructions) and/or data. [0136] In alternative implementations, secondary memory 1010 includes other similar means for allowing computer software and/or data to be loaded into computer system 1000. Such means include, for example, a removable storage unit 1022 and an interface 1020. Examples of such means include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as, an EPROM or PROM) and associated socket, and other removable storage units 1022 and interfaces 1020 which allow software and data to be transferred from the removable storage unit 1022 to computer system 1000. [0137] Computer system 1000 can also include a communications interface 1024. Communications interface 1024 allows software and/or data to be transferred between computer system 1000 and external devices. Examples of communications interface 1024 include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 1024 are in the form of signals 1028 which can be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 1024. These signals 1028 are provided to communications interface 1024 via a communications path (i.e., channel) 1026. Communications path 1026 carries signals 1028 and can be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, free-space optics, and/or other communications channels. [0138] In this document, the terms �computer program medium� and �computer usable medium� are used to generally refer to media such as removable storage unit 1018, removable storage unit 1022, a hard disk installed in hard disk drive 1012, and signals 1028. These computer program products are means for providing software to computer system 1000. The invention, in an embodiment, is directed to such computer program products. [0139] Computer programs (also called computer control logic or computer readable program code) are stored in main memory 1008 and/or secondary memory 1010. Computer programs can also be received via communications interface 1024. Such computer programs, when executed, enable the computer system 1000 to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 1004 to implement the processes of the present invention, such as the method(s) implemented using components of OLT 102 and/or ON 106 described above, such as various steps of methods 400, 500, 600, and/or 700, for example. Accordingly, such computer programs represent controllers of the computer system 1000. [0140] In an embodiment where the invention is implemented using software, the software can be stored in a computer program product and loaded into computer system 1000 using removable storage drive 1014, hard drive 1012, interface 1020, or communications interface 1024. The control logic (software), when executed by the processor 1004, causes the processor 1004 to perform the functions of the invention as described herein. [0141] In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to one skilled in the relevant art(s). [0142] In yet another embodiment, the invention is implemented using a combination of both hardware and software. [0143] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to one skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the invention. Moreover, it should be understood that the method, system, and computer program product of the present invention could be implemented in any multi-nodal communications environment governed by centralized nodes. The nodes include, but are not limited to, cable modems and headends, as well as communication gateways, switches, routers, Internet access facilities, servers, personal computers, enhanced telephones, personal digital assistants (PDA), televisions, set-top boxes, or the like. Thus, the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7805287Jun 5, 2003Sep 28, 2010Verizon Laboratories Inc.Node emulatorUS7844432 *Jun 16, 2004Nov 30, 2010Verizon Laboratories Inc.Node emulatorUS8073329 *Dec 18, 2006Dec 6, 2011Huawei Technologies Co., Ltd.Passive optical network user terminal and method of power supply control and power supply state reporting for the sameUS8144706 *Apr 2, 2010Mar 27, 2012Marvell International Ltd.Method and apparatus for managing packets in a packet switched networkUS8452178Oct 11, 2011May 28, 2013Huawei Technologies Co., Ltd.Passive optical network user terminal and method of power supply control and power supply state reporting for the sameUS8705355Mar 5, 2013Apr 22, 2014Marvell International Ltd.Network switch and method for asserting flow control of frames transmitted to the network switchUS8819161Nov 30, 2010Aug 26, 2014Marvell International Ltd.Auto-syntonization and time-of-day synchronization for master-slave physical layer devicesUS20080199180 *Apr 21, 2008Aug 21, 2008Huawei Technologies Co., Ltd.Optical network terminal and a message processing method, a message processing apparatus and system thereofWO2004034643A1 *Oct 7, 2003Apr 22, 2004Claret Jorge Vicente BlascoMethod of implementing virtual local area networks on electrical network communication systemsWO2007121666A1 *Apr 18, 2007Nov 1, 2007Huawei Tech Co LtdA management method for passive optical network terminal and system thereof* Cited by examinerClassifications U.S. Classification370/392International ClassificationH04Q11/00Cooperative ClassificationH04Q11/0067, H04Q2011/0064, H04Q11/0071, H04Q2011/0047European ClassificationH04Q11/00P4CLegal EventsDateCodeEventDescriptionMay 12, 2011SULPSurcharge for late paymentMay 12, 2011FPAYFee paymentYear of fee payment: 4Feb 21, 2011REMIMaintenance fee reminder mailedMay 31, 2007ASAssignmentOwner name: BROADCOM CORPORATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SALA, DOLORS;LIMB, JOHN O.;GUMMALLA, AJAY CHANDRA V.;REEL/FRAME:019362/0949;SIGNING DATES FROM 20021215 TO 20030210RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google