US8068460B2 - Dynamic packet buffering system for mobile handoff - Google Patents
Dynamic packet buffering system for mobile handoff Download PDFInfo
- Publication number
- US8068460B2 US8068460B2 US11/162,199 US16219905A US8068460B2 US 8068460 B2 US8068460 B2 US 8068460B2 US 16219905 A US16219905 A US 16219905A US 8068460 B2 US8068460 B2 US 8068460B2
- Authority
- US
- United States
- Prior art keywords
- buffering
- mobile device
- node
- buffer
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related, expires
Links
- 230000003139 buffering effect Effects 0.000 title claims abstract description 223
- 238000000034 method Methods 0.000 claims abstract description 85
- 230000007246 mechanism Effects 0.000 claims abstract description 24
- 230000008569 process Effects 0.000 claims abstract description 18
- 239000000872 buffer Substances 0.000 claims description 143
- 235000016936 Dendrocalamus strictus Nutrition 0.000 claims description 31
- 230000011664 signaling Effects 0.000 claims description 26
- 238000011010 flushing procedure Methods 0.000 claims description 24
- 238000004891 communication Methods 0.000 claims description 18
- 230000005540 biological transmission Effects 0.000 claims description 11
- 230000004044 response Effects 0.000 claims description 6
- 230000001052 transient effect Effects 0.000 claims description 2
- 230000007781 signaling event Effects 0.000 claims 1
- 238000007726 management method Methods 0.000 description 17
- 239000003795 chemical substances by application Substances 0.000 description 8
- 230000006399 behavior Effects 0.000 description 7
- 230000000694 effects Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000005457 optimization Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 238000012384 transportation and delivery Methods 0.000 description 3
- XQVWYOYUZDUNRW-UHFFFAOYSA-N N-Phenyl-1-naphthylamine Chemical compound C=1C=CC2=CC=CC=C2C=1NC1=CC=CC=C1 XQVWYOYUZDUNRW-UHFFFAOYSA-N 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 230000005641 tunneling Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
- H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Definitions
- the present application relates to wireless networking and, in some preferred embodiments, to methods of improving handoff of a mobile device between neighboring networks and/or the like.
- the Internet is a worldwide network of computer networks.
- Today, the Internet is a public and self-sustaining network that is available to many millions of users.
- the Internet uses a set of communication protocols called TCP/IP (i.e., Transmission Control Protocol/Internet Protocol) to connect hosts.
- TCP/IP i.e., Transmission Control Protocol/Internet Protocol
- the Internet has a communications infrastructure known as the Internet backbone. Access to the Internet backbone is largely controlled by Internet Service Providers (ISPs) that resell access to corporations and individuals.
- ISPs Internet Service Providers
- IP Internet Protocol
- IP Internet Protocol
- PDA Personal Digital Assistant
- IP Internet Protocol
- IP Internet Protocol
- IPv4 IPv6
- Each host device on the network has at least one IP address that identifies the host device's point of attachment to the IP networks.
- the connection between end points during a communication is not continuous.
- OSI Open Systems Interconnection
- the OSI model separates the communications processes between two points in a network into seven stacked layers, with each layer adding its own set of functions. Each device handles a message so that there is a downward flow through each layer at a sending end point, and an upward flow through the layers at a receiving end point.
- the programming and/or hardware that provides the seven layers of function is typically a combination of device operating systems, application software, TCP/IP and/or other transport and network protocols, and other software and hardware.
- the top four layers are used when a message passes from or to a user and the bottom three layers are used when a message passes through a device (e.g., an IP host device).
- An IP host is any device on the network that is capable of transmitting and receiving IP packets, such as a server, a router, or a workstation. Messages destined for some other host are not passed up to the upper layers but are forwarded to the other host.
- IP is in Layer-3, the network layer.
- the layers of the OSI model are listed below.
- Layer 7 i.e., the application layer
- Layer 7 is a layer at which, for example, communication partners are identified, quality of service is identified, user authentication and privacy are considered, constraints on data syntax are identified, and the like.
- Layer 6 i.e., the presentation layer
- Layer 5 i.e., the session layer
- Layer-4 i.e., the transport layer
- Layer-3 i.e., the network layer
- Layer-3 is a layer that, for example, handles routing and forwarding, and the like.
- Layer-2 (i.e., the data-link layer) is a layer that, for example, provides synchronization for the physical level, does bit-stuffing and furnishes transmission protocol knowledge and management, and the like.
- the Institute of Electrical and Electronics Engineers (IEEE) sub-divides the data-link layer into two further sub-layers, the MAC (Media Access Control) layer that controls the data transfer to and from the physical layer and the LLC (Logical Link Control) layer that interfaces with the network layer, interprets commands, and performs error recovery.
- Layer 1 (i.e., the physical layer) is a layer that, for example, conveys the bit stream through the network at the physical level.
- the IEEE sub-divides the physical layer into the PLCP (Physical Layer Convergence Procedure) sub-layer and the PMD (Physical Medium Dependent) sub-layer.
- layers higher than layer-2 (such as, for example, layers including the network layer or layer-3 in the OSI model and the like) is referred to as the higher-layers.
- Wireless networks can incorporate a variety of types of mobile devices, such as, e.g., cellular and wireless telephones, PCs (personal computers), laptop computers, wearable computers, cordless phones, pagers, headsets, printers, PDAs, etc.
- mobile devices may include digital systems to secure fast wireless transmissions of voice and/or data.
- Typical mobile devices include some or all of the following components: a transceiver (i.e., a transmitter and a receiver, including, for example, a single chip transceiver with an integrated transmitter, receiver and, if desired, other functions); an antenna; a processor; one or more audio transducers (for example, a speaker or a microphone as in devices for audio communications); electromagnetic data storage (such as, for example, ROM, RAM, digital data storage, and the like, such as in devices where data processing is provided); memory; flash memory; a full chip set or integrated circuit; interfaces (such as, for example, USB, CODEC, UART, PCM, etc.); and/or the like.
- a transceiver i.e., a transmitter and a receiver, including, for example, a single chip transceiver with an integrated transmitter, receiver and, if desired, other functions
- an antenna a processor
- one or more audio transducers for example, a speaker or a microphone as in devices for audio communications
- Wireless LANs in which a mobile user can connect to a local area network (LAN) through a wireless connection may be employed for wireless communications.
- Wireless communications can include, for example, communications that propagate via electromagnetic waves, such as light, infrared, radio, microwave.
- electromagnetic waves such as light, infrared, radio, microwave.
- WLAN standards There are a variety of WLAN standards that currently exist, such as, e.g., Bluetooth, IEEE 802.11, and HomeRF.
- Bluetooth products may be used to provide links between mobile computers, mobile phones, portable handheld devices, personal digital assistants (PDAs), and other mobile devices and connectivity to the Internet.
- PDAs personal digital assistants
- Bluetooth is a computing and telecommunications industry specification that details how mobile devices can easily interconnect with each other and with non-mobile devices using a short-range wireless connection.
- Bluetooth creates a digital wireless protocol to address end-user problems arising from the proliferation of various mobile devices that need to keep data synchronized and consistent from one device to another, thereby allowing equipment from different vendors to work seamlessly together.
- Bluetooth devices may be named according to a common naming concept. For example, a Bluetooth device may possess a Bluetooth Device Name (BDN) or a name associated with a unique Bluetooth Device Address (BDA).
- BDN Bluetooth Device Name
- BDA unique Bluetooth Device Address
- Bluetooth devices may also participate in an Internet Protocol (IP) network. If a Bluetooth device functions on an IP network, it may be provided with an IP address and an IP (network) name.
- IP Internet Protocol
- a Bluetooth Device configured to participate on an IP network may contain, for example, a BDN, a BDA, an IP address, and an IP name.
- IP name refers to a name corresponding to an IP address of an interface.
- IEEE 802.11 An IEEE standard, IEEE 802.11, specifies technologies for wireless LANs and devices. Using 802.11, wireless networking may be accomplished with each single base station supporting several devices. In some examples, devices may come pre-equipped with wireless hardware or a user may install a separate piece of hardware, such as a card, that may include an antenna.
- devices used in 802.11 typically include three notable elements, whether or not the device is an access point (AP), a mobile station (STA), a bridge, a PCMCIA card or another device: a radio transceiver; an antenna; and a MAC (Media Access Control) layer that controls packet flow between points in a network.
- AP access point
- STA mobile station
- bridge a PCMCIA card
- PCMCIA card PCMCIA card
- MIDs may be utilized in some wireless networks.
- MIDs may contain two or more independent network interfaces, such as a Bluetooth interface and an 802.11 interface, thus allowing the MID to participate on two separate networks as well as to interface with Bluetooth devices.
- the MID may have an IP address and a common IP (network) name associated with the IP address.
- Wireless network devices may include, but are not limited to Bluetooth devices, Multiple Interface Devices (MIDs), 802.11x devices (IEEE 802.11 devices including, e.g., 802.11a, 802.11b and 802.11g devices), HomeRF (Home Radio Frequency) devices, Wi-Fi (Wireless Fidelity) devices, GPRS (General Packet Radio Service) devices, 3G cellular devices, 2.5G cellular devices, GSM (Global System for Mobile Communications) devices, EDGE (Enhanced Data for GSM Evolution) devices, TDMA type (Time Division Multiple Access) devices, or CDMA type (Code Division Multiple Access) devices, including CDMA2000.
- MIDs Multiple Interface Devices
- 802.11x devices IEEE 802.11 devices including, e.g., 802.11a, 802.11b and 802.11g devices
- HomeRF Home Radio Frequency
- Wi-Fi Wireless Fidelity
- GPRS General Packet Radio Service
- 3G cellular devices 2.5G cellular devices
- GSM Global System for
- Each network device may contain addresses of varying types including but not limited to an IP address, a Bluetooth Device Address, a Bluetooth Common Name, a Bluetooth IP address, a Bluetooth IP Common Name, an 802.11 IP Address, an 802.11 IP common Name, or an IEEE MAC address.
- Wireless networks can also involve methods and protocols found in, e.g., Mobile IP (Internet Protocol) systems, in PCS systems, and in other mobile network systems. With respect to Mobile IP, this involves a standard communications protocol created by the Internet Engineering Task Force (IETF). With Mobile IP, mobile device users can move across networks while maintaining their initially assigned IP Address. Mobile IP enhances Internet Protocol (IP) and adds a means to forward Internet traffic to mobile devices when connecting outside their home network. Mobile IP assigns each mobile node a home address on its home network and a care-of-address (CoA) that identifies the current location of the device within a network and its subnets. When a device is moved to a different network, it receives a new care-of address. A mobility agent on the home network can associate each home address with its care-of address. The mobile node can send the home agent a binding update each time it changes its care-of address using, as for example, the Internet Control Message Protocol (ICMP).
- ICMP Internet Control Message Protocol
- node In basic IP routing (i.e. outside mobile IP), typically, routing mechanisms rely on the assumptions that each network node always has a constant attachment point to, for example, the Internet and that each node's IP address identifies the network link to which it is attached.
- the terminology “node” includes a connection point, which can include, for example, a redistribution point or an end point for data transmissions, and which can recognize, process and/or forward communications to other nodes.
- Internet routers can look at, for example, an IP address prefix, or the like, identifying a device's network. Then, at a network level, routers can look at, for example, a set of bits identifying a particular subnet.
- routers can look at, e.g., a set of bits identifying a particular device.
- a user disconnects a mobile device from, for example, the Internet and tries to reconnect it at a new subnet, then the device has to be reconfigured with a new IP address, a proper netmask, and a default router. Otherwise, routing protocols would not be able to deliver the packets properly.
- a mobile device with an IP-based wireless network interface such as, e.g., an IEEE 802.11 or an 802.16 interface
- the mobile device needs to perform roaming or handoffs when it moves from one network into another network.
- handoff is typically accomplished by performing the following sequence of protocol layer specific handoffs.
- handoff takes place at the physical layer.
- the mobile device switches its radio channel to, e.g., a wireless base station or wireless access point in the target network.
- the mobile device switches its layer-2 (i.e., link-layer) connections to the target network.
- layer-2 i.e., link-layer
- the link layer or layer-2 refers to the protocol immediately below the IP-layer that carries user traffic.
- the mobile device performs layer-2 authentication with the target network if the target network requires such authentication.
- the mobile device obtains a local IP address from the target network, performs IP-layer authentication if required by the target network, and then performs IP-layer location update so that IP packets destined to the mobile device can be routed by the IP network to the mobile device via the target network.
- IP layer location update is to use Mobile IP defined by the Internet Engineering Task Force (IETF).
- handoff takes place at the application-layer.
- the mobile device performs necessary steps at the application layer to ensure that its application traffic will flow correctly to the applications on the mobile device via the target network.
- SIP Session Initiation Protocol
- an application layer handoff can be achieved by the mobile device updating its current location with its home SIP server.
- the mobile device may also need to carry out application-layer authentication with the target network if required by the target network.
- IMS IP Multimedia Subsystem
- 3GPP 3 rd Generation Partnership Project
- IP-layer handoff or application-layer handoff is sufficient. That is, it may be unnecessary to perform both IP-layer and application-layer handoff.
- WLANs wireless local area networks
- a mobile device may receive strong radio signals from multiple radio networks at the same time. However, the mobile device may not be authorized to use some of these radio networks.
- a mobile device will select a target network based on, for example, radio signal strengths, and will go through the steps described above to connect to the target network and then discover, for example, if it is authorized to use the network or if the network does not provide the capabilities (e.g., sufficient available bandwidth) or the services that the mobile device needs. Consequently, the mobile device will have to try to connect to another network, and will repeat this process until it finally connects to a network that provides, and that allows it to use, the capabilities and services it needs (or until it has exhausted all possible networks). Accordingly, with existing systems, a handoff can take a long time that can be intolerable and can delay sensitive applications such as, as some examples, live voice, and/or video applications.
- a broad aspect of the preferred embodiments of the present invention is the handing off without packet loss, between a mobile device traveling along a series of neighboring networks and correspondent node.
- the mobile node can encounter a period during which there is no network connectivity when moving from one network to another.
- Negating handoff packet loss can be achieved through the use of a per-mobile packet buffer that is located on an access router, a network node near the edge of the network from which the mobile is moving away, a network node near the edge of the network that the mobile is moving towards, and/or a mobile node.
- the buffered packets are forwarded to the mobile node when the handoff process is completed.
- Another aspect of the preferred embodiments is the use of the buffering in conjunction with existing mobility protocols, access protocols, or as an independent network or link layer mechanism and the protocol used for buffering control is defined as a separate protocol, such that the system is universally compatible with mobility management protocols.
- the buffering control protocol signals events and parameters between the mobile device and the mobile node.
- Another aspect of the preferred embodiments defines the tunnel establishment mechanism used for forwarding buffered packets to the mobile node, to provide independency of mobility management protocols.
- Another aspect of the preferred embodiments is the buffering of packets that are in transit during the handoff period in a buffer node. Upon completion of handoff, the buffered packets are flushed and forwarded to the mobile device in its new location.
- a buffering node can be provided in the mobile device for buffering egress packets during the handoff period in the mobile device buffer node, and buffer node can be provided at the network edge for buffering packets that are sent from the network edge buffer not to the mobile device.
- Providing buffering nodes at the mobile device and at the mobile devices provides bi-directional buffering during handoff and compensating for packet loss in both directions.
- pre-handoff traffic reaches the mobile device via the previous network prior to handoff.
- the mobile device When the mobile device is ready to move to a new network, it signals the buffer node of its intent and the buffer node begins to buffer traffic destined for the mobile device.
- the mobile device Upon completion of handoff the mobile device signals the buffer node to flush buffered packets and forward the buffered packets to the mobile device in its new network, the buffer node may reside on a node that requires temporary buffering support, and can reside on either a previous access router, a next access router, or the mobile device.
- a buffer node is a network entity that intercepts packets destined for one or more mobile device and temporally buffers the packets to avoid packet loss while a mobile devices is in the handoff process, the buffer node classifies packets for each mobile node, buffers classified packets, and forwards buffered packets appropriately after handoff is completed, and wherein each of these steps is signaled by a mobile device that requests buffering service.
- the existing buffering control protocol signals the forwarding of the buffered packets after a positive end of service, the buffer node having been provided with the current care-of-address of the mobile device when it starts flushing the buffered packets.
- the buffering control protocol also signals to the buffer node the current care-of-address of the mobile node prior to flushing and forwarding of buffered packets.
- the buffered packets are sent locally to the mobile device, and when the mobile device and the buffer node are on different IP links, the buffered packets are sent to its next hop router towards the mobile device and are routed to the mobile device using IP routing.
- ⁇ TC “Buffering Phase” ⁇ f C ⁇ I “3” ⁇ a buffering phase spans the period during which traffic classification and buffering is occurring, beginning immediately after the buffer node responds to the initial buffering request indicating that buffering service is being provided and ends when an end of service condition is met.
- the buffer node and the mobile device can exchange one or more extension requests, and wherein each exchange completes an extension request negotiation.
- the buffering control protocol enables the mobile node to specify the type of traffic to be buffered (traffic classification). This allows the mobile node the flexibility of signaling to the buffer node to buffer traffic of interest only. This also assists the buffer node in reducing resource allocation needs for the buffering request.
- Another aspect of the preferred embodiments defines that the buffering node to adjust and negotiate the resources to be allocated in performing the buffering service.
- the amount of resource to allocated are computed on a per request basis and takes into account the handoff requirement of the mobile node as well as the availability of resources in the buffering node. Such negotiation is part of the buffering control protocol.
- Another aspect of the preferred embodiments defines the buffering node to be present in mobile node. This assists software applications present in the mobile node that is sending packets.
- the transmitted packets are buffered when handoff is occurring.
- the signaling of the mobile node to the buffer node is done locally.
- the destination IP address of the buffered packets are left unchanged and will be routed via normal IP routing.
- FIG. 1 is a diagrammatic representation of a Packet Buffering Model with access router acting as BN;
- FIG. 2 is a diagrammatic representation of Packet Buffering with pre-authentication/provisioning
- FIG. 3 is a diagrammatic representation of a Buffering Node (BN) located in MN for Outgoing Packets; and
- FIG. 4 is an illustration of the BCP protocol flow.
- MN Mobile node
- CN Correspondent Node
- BN Buffering Node
- FP Flushing Policy
- BCP Buffering Control Protocol
- EOS End of Service
- Buffer Size bsz
- hp Time-limited Timeout
- tc Classified Traffic
- CoA Care-of Address
- rcode Result Code
- the present invention provides a solution beyond the application end points by providing a per-mobile packet buffer at an access router or network entity (Buffering Node) near the edge of the network where the mobile is moving away from or moving towards. Packets that are in transit during the handoff period will be buffered in the Buffering Node (BN). When handoff completes, the buffered packets will be flushed and forwarded to the MN in its new location. This approach provides zero packet loss for all packets destined for the MN that have reached the BN.
- the solution also describes a buffering scheme that enables the MN to have greater granular control over the behavior of the BN to help reduce the overall handoff delay.
- Outgoing packets sent by the MN during the handoff period can be also be lost during the handoff process.
- a BN can also be implemented locally in the MN to provide a buffering solution for egress packets during the handoff period. Having a BN in both the MN and the network edge provides bi-directional buffering during handoff and compensates for packet loss in both directions.
- the BN may also be located within the access point specifically to assist an MN that performs active scanning. When an MN performs active scans on channels different from the currently associated access point it can no longer receive packets from that access point.
- One embodiment of the uses MN power saving mode to signal scenario to the access point and enables it to start buffering on behalf of the MN.
- Implementing a BN on the access point itself provides the same functionality with better control on the buffering period and buffer size, as described in 2.1.6.
- the present method can work with any mobility management protocol by defining the buffering control protocol as a separate protocol.
- location of buffering node is limited to mobility agents such as home agent and mobility anchor point.
- the present method provides more flexibility on location of buffering node.
- forwarding of buffered packets to the mobile node after completion of the handover period depends heavily on the forwarding behavior of the mobility agent of the coupled mobility management protocol.
- the present method defines its own tunnel establishment mechanism used for forwarding buffered packets to the mobile node to provide perfect independency of mobility management protocols.
- Reference [1] describes the use of adding a P-bit in the mobility header of BU (Binding Update) and LBU (Local Binding Update) messages.
- the value of the P-bit indicates to the HA (Home Agent) when to buffer (P-bit is ‘1’) and when to forward the packets (P-bit is ‘0’).
- the approach is limited in comparison to some embodiments of the present methods where, e.g., dynamic negotiations can occur and multiple behaviors at end of buffering can be selected.
- Reference [2] describes a Mobile IPv4 buffering protocol that resembles the method presented by the present invention.
- the closest similarity is the explicit definition of a control protocol to manage buffering duration, negotiate buffer size as well as traffic flow identification information (IP traffic filters).
- IP traffic filters IP traffic filters.
- reference [2] recommends explicit signaling to determine the duration of the buffering period but also implies a lease time to the buffer.
- the present method may have some similarities in function, it works beyond the Mobile IPv4 topology and the BN's location is not limited to the FA (Foreign Agent) or HA (Home Agent).
- Reference [4] is a Mobile IPv6 version of [2] and describes a similar mechanism.
- a feature present in the invention that is not supported by the existing methods is buffer management discovery. It takes advantage of IPv6 router advertisement to check the buffering capability of a network. Overall, the methods described in [4] and [2] are substantially identical.
- References [8, 9, and 10] provide alternative mechanisms to reduce packet loss without the use of any buffer management protocol and depend heavily on the cooperation of the end clients.
- a BN there are two (2) major components required for the buffering scheme, a BN, and a buffering control protocol (BCP).
- BCP buffering control protocol
- the BCP signals events and parameters between the MN and the BN. It is a reliable protocol composed of request (BReq) and answer (BAns) pairs with re-transmission capabilities.
- BReq request
- BAns answer
- the BCP is discussed in detail in Section 3.
- a Packet Buffering Model with access router acting as BN is illustrated in FIG. 2 .
- the buffering model is best described using traffic flows 116 , 122 , and 104 going towards the MN 102 .
- pre-handoff traffic 118 reaches the MN 102 via the previous network 110 .
- MN decides to move to the new network 112 , it explicitly signals the BN 106 of its intent.
- BN 106 then starts to buffer traffic 116 , destined for the MN 102 that is still being forwarded through the previous network 110 .
- MN 102 signals BN 106 (explicit or implicit), as indicated by line 120 , to flush the buffered packets 104 and forward it to the MN 102 in the new network 112 .
- BN can reside on any node that requires temporary buffering support as discussed in Sec 2.1.6.
- previous access router 108 , next access router 109 , and the mobile device 102 can all have the buffering capability.
- Post handoff traffic with route optimization between the correspondent node 100 and MN 102 is represented by flow line 114 .
- Flow line 122 shows the post handoff traffic with care-of-address between the CN and the MN 102 .
- the BCP signals events and parameters between the MN and the BN. It is a reliable protocol composed of request (BReq) and answer (BAns) pairs with re-transmission capabilities.
- the BCP is discussed in detail in Sec 3.
- a buffering node is a network entity that intercepts packets destined for one or more MN and temporally buffers them in order to avoid packet loss while the MN(s) is in the handoff process. To do this, the BN has to be able to classify packets for each MN, buffer the packets, and forward the buffered packets appropriately after handoff is completed. In addition, each of these steps is signaled by an MN that requests buffering service.
- BN is a passive entity. MN uses the BCP to request buffering service from the BN. The protocol also communicates buffering request result and error conditions including signaling errors. BN only responds to request (sends a BAns for each BReq received) but never generates them.
- the BCP is discussed in detail in Sec 3.
- the BN must be able to classify traffic and allocate buffers dynamically for each MN asking for service. Classification of the traffic that must be buffered is dictated by the MN when it sends a BReq[initial]. [initial] specifies the signal type (initial) and signal parameters sent by the MN including traffic classification information. The MN may be interested only in buffering certain types of traffic as opposed to all traffic destined for the MN. If classification information is not provided by the MN, the BN should buffer all traffic for the MN.
- the size of the buffer allocated by BN can also be negotiated by the MN in BReq[initial].
- the MN may have prior knowledge of the length of the handoff period and traffic rate and thereby be able to compute a reasonable value for buffer size (bsz).
- the BN can impose a limit on this value to conserve memory resources. Therefore, the BN dictates the final value for the bsz. This final value is communicated back to the MN by the BN as part of BAns[initial]. If the value imposed by the BN is unacceptable to the MN then the MN may withdraw its request for buffering service by signaling a BReq[stop] to the BN indicating its intent to terminate the buffering service.
- the MN may also indicate in the Breq[initial] if the bsz it proposes is amount it requires and it cannot accept any less.
- the MN can indicate this by setting mandatory flag (flag.m) in Breq[initial] parameters.
- the BN In the case where the BN cannot accommodate this requirement, then the BN immediately terminates the service and communicates the error back to the MN via BAns[initial]. In such a case, the BN should not even keep state information regarding the service.
- the value of the bsz is set during the initial negotiation, it can also be dynamically adjusted during the course of buffering service. Details can be found in Sec 3.3.2.
- buffering Since the buffering service is a transient service, buffering begins once BN has received a BReq[initial] from an MN and negotiated values have been established. State information regarding the service is then maintained by the BN. If for some reason the BN is not able to accommodate the initial request, it may communicate this failure to the MN as part of the BAns[initial] as described in Sec 2.1.7.
- the buffering service should at least encompass the handoff period for which the MN is not able to send or receive IP packets. The termination of the buffering period is the end of service (EOS) duration that can have a positive or negative outcome.
- EOS end of service
- a buffering period (bp) with a positive outcome can be determined using both time-limited and explicit signaling method, as described in Sections 2.1.3.1 and 2.1.3.2, respectively. Both methods are mutually exclusive but complementary since one can be used to pre-empt the other.
- a buffering period with a negative outcome occurs when error conditions are met as described in Sec 2.1.7.
- the BN and MN can negotiate a time-limited timeout value (bp) to determine the EOS. Expiration of the timeout prior to an explicit receipt of BReq[stop] constitutes a positive EOS and enforcement of existing flushing policy (FP) as described in Sec 2.1.4. A large bp value can cause the buffer to overflow. In such a case, buffer overflow contingencies are be performed as described in Sec 2.1.71.
- the length of the timeout encompasses the handoff period for which the MN is not able to send or receive IP packets.
- BReq[stop] Prior to expiration of a previously established bp value constitutes a positive EOS and enforcement of existing FP. See As described in Sec 2.1.4.
- Prior BReq[ext] signals may also have carried a new FP value that overrides any existing policy. In such a case, the new FP should be enforced.
- the duration of the explicit signal should encompass the handoff period for which the MN is not able to send or receive IP packets.
- Explicit signaling may be used together with the time-limited buffering. It can also be used to accommodate dynamic behavior of the network such as a change in the buffer size requirement.
- Error conditions that occur during buffering service which forces the buffering service to terminate should constitute a negative EOS. Any existing FP may be enforced if the BN attempts to perform limited recovery. In general, however, error conditions should be treated fatal and all resources and state information allocated to the service should be released to the system. See 2.1.7.
- the BReq[initial] as well as subsequent BReq sent by the MN dictates the policy that the BN enforces against any buffered packets once EOS is met.
- the flushing policy (FP) enforced by the BN either forwarding, dropping the buffered packets to sending explicit error notification to the MN using the BCP or an out-band mechanism such as ICMP.
- FP flushing policy
- BReq[initial] from the MN contains the default FP enforced by the BN once buffering service ends without receipt of any subsequent BReq[ext] overriding the default FP. Subsequent BReq[ext] containing a new FP overrides any previously established FP.
- the BN When the existing FP forwards the buffered packets after a positive EOS, the BN must be able to know the current CoA of the MN when it starts flushing the buffered packets.
- the current CoA of the MN may be the same as that is registered in the BN, or may be different if the MN has changed its CoA after registering with the BN.
- the BCP itself has a mechanism to indicate to the BN the current CoA of the MN, when the BN starts flushing the buffered packets. This is achieved by including the current CoA of the MN in the BReq[stop] message.
- the BCP may include the CoA in BReq[ext] signal prior to expiration of the bp.
- the BN may use the last signaled CoA if more than one BReq[ext] is sent by the MN that has differing CoA.
- flushing the buffered packets and forwarding of the buffered packets is performed as follows.
- the buffered packets are sent locally to the MN by using the address resolution protocol (ARP). Otherwise, if the MN and BN are on different IP links, the buffered packets are sent to its next hop router towards the MN and are routed to the MN using IP routing. In the latter case, the buffered packets can be carried in an IP tunnel between the BN and the current CoA of the MN. If this IP tunnel does not exist prior to performing explicit signaling to stop buffering, it is established by the explicit signaling via a BReq[stop] and BAns exchange or bp expiration.
- ARP address resolution protocol
- the BN must maintain a mapping between the current CoA and the CoA of the MN in the previous network, as part of the IP tunnel establishment. IP routing of the buffered packets can then result in forwarding of the packets through the IP tunnel. In some cases where this IP tunnel is established via a mobility management/optimization protocol such as FMIP6 [3], the tunnel is be used for forwarding the buffered packets instead of creating another tunnel.
- a mobility management/optimization protocol such as FMIP6 [3]
- the BN can be able to modify the destination address of the buffered IP packets. During forwarding, the BN can set the destination IP address of the buffered packets to the current CoA. The packets will then be forwarded via normal IP routing towards the current CoA. This reduces the additional management associated with establishing and maintaining an IP tunnel to the MN. It also assists in the case where the IP mobility management protocol may not have tunneling functionality available or if there is no mobility management protocol in use.
- the BN can be placed at any node that is on the communication path between the MN and the CN, it is preferred to place the BN either at the previous access router to which the MN is attached before handoff, as shown in FIG. 1 , or at the new access router, as shown in FIG. 2 , to which the MN is attached after handoff.
- FIG. 2 shows Packet Buffering with pre-authentication/provisioning and in the case where the BN 214 is located on the new network, it maybe assumed that some pre-authorization and pre-provision is done prior to the MN moving.
- the pre-provisioning procedure enables the BN to determine the address of the MN even prior to moving without the aid of any mobility protocols. In all cases however, whether the BN is located in the previous or new network, the same architecture can be adapted and interaction between BN and MN does not change.
- Access router 204 is in the previous network 216 , and the access router (BN) 205 , in the new network 218 .
- Flow line 206 represents the pre-handoff traffic between CN 202 and MN 200 .
- Flow line 210 represents post handoff traffic between the correspondent node 102 and MB 200 .
- Flow line 212 represents the buffered traffic between CN 202 and BN 214 .
- the flow line 208 represents signaling between the MN 200 and the BN 214 .
- Another location of the BN can be within the MN itself, as illustrated in FIG. 3 .
- the access router 314 is in the new network 302
- access router 318 is in the previous network 300 .
- Flow line 312 represents the buffered traffic between CN 304 and the MN 324 .
- the flow line 306 represents pre-handoff traffic from the MN to the CN.
- Flow line 308 represents signaling between the MN and the buffer node 310 .
- Flow line 316 represents post-handoff traffic from the BN 310 to the CN 304 .
- FIG. 3 shows a Buffering Node (BN) located in MN 324 for Outgoing Packets.
- the BN serves as a buffering service to outgoing packets for the MN during the handoff period.
- This usage is mutually exclusive and complements the BN locations previously disclosed.
- a BN present in the MN bi-directional buffering can be achieved.
- the architecture of the BN and its interaction with the MN does not change.
- a BN in the MN also helps in case of ping-pong effects during handoff. Ping-pong effects occur, e.g., when the MN fails complete handoff in the new network and re-associates itself to the previous network. In such a case, the BN acts as recovery mechanism for packets that may have been lost during the failed handoff attempt.
- the forwarding behavior of the buffered packets is determined solely by the destination address of each packet. In addition, no external signaling is needed for buffering outgoing packets at MN.
- Reference [11] discusses buffering outgoing traffic to provide congestion control, however it does not specifically deal with mobility scenario.
- the BN may also be located within the previous access point to assist in buffering packets when the MN is actively scanning for finding a new access point or testing connectivity to a new access point.
- Error conditions or negative EOS can occur because of the following.
- a BN may receive a BReq[initial] for an MN for which it cannot comply due to resource limitations. This may happen when the BN's resource is already limited due to existing buffering service provided to other MN's. This may also occur if the BN decides that the parameters imposed by the MN in BReq[initial] is greater than the total amount of resource that can be provided by the system. In such cases, the BN can communicate this failure to the MN in the BAns[initial] notifying the MN of the BN's inability to provide the requested service. The BN should not keep any state information for the requested service. The MN may choose to re-submit a new BReq[initial] with an adjusted value. In such a case, the BN will treat this as a new request for service.
- Buffer overflow occurs when the number of packets being queued by the BN has exceeded the capacity of the allocated buffer before the buffer EOS has been met as described in Sec 2.1.3. In such a case, it may not be possible for the BN to communicate the situation to the MN and negotiate subsequent actions such as extending the buffering period via BReq[ext]. MN may be in the middle of handoff process so the BN should take the following action based on previously configured administrative policies.
- the BN can choose to maintain only the currently buffered packets and drop subsequent newly arrived packets (tail drop). Once the end of buffer duration is met, it can enforce the existing FP as described in 2.1.4. This enables the BN to limit the number of packets that the MN would loose.
- the BN may choose to completely terminate the buffering service and release all resources associated with it.
- the MN can be able to learn of the BN's action once subsequent BReq/BAns signaling is exchanged.
- the BN can silently discard all the relevant state it keeps for the associated buffering service if such signaling does not occur when the end of buffer duration is met.
- the buffer control protocol provides a re-transmission and error handling features that can indicate this event.
- the BN can act appropriately depending on the severity of the error as discussed in Sec 3.5.
- System failures can include memory depletion, total network connectivity failure, or other faults where the host or system that BN resides enters an unstable and unusable state. Any events or conditions that results in such a state can be considered fatal and render the BN inoperable. The actions taken by the BN upon such events will depends on the severity of the condition and recoverability schemes in place in the system. In such a case, the availability of the BN is determined by its implementation.
- the priority of the buffered packet should be maintained against any newly arrived post-handoff packets in order to avoid out-of-order delivery of packets.
- An additional forwarding queue maybe implemented in addition to the BN's main buffer.
- the forwarding queue maybe used to store newly arrived post-handoff packets destined for the MN while the BN's buffer is being flushed. This has the effect of having two buffers used in sequence. Flushing of the buffers is exclusive with the main buffer having higher priority over the forwarding queue.
- traffic control queues i.e. Linux traffic control module
- Some systems implement an interface receiver queue (network driver rx queue) to buffer incoming packets before being forwarded by the system.
- the BN can utilize this feature by pre-empting the processing of packets stored in this queue.
- the BN can pre-empt the system and flush its buffers before the system begins routing packets stored in the receiver queue.
- One caveat is that the receiver queue holds all incoming packets for that interface. Therefore, pre-empting the processing of the receiver queue would generally delay delivery of all packets and not just packets for the MN.
- the flushing and forwarding rate in the BN after a positive EOS should be greater than the receive rate of the newly arrived post-handoff packets. If this is not the case, there is a greater possibility that the queue holding the post-handoff packets (2.2.1.1 and 2.2.1.2) will be filled before the BN's buffer is empty. This will result in over flow of post-handoff queues and eventually packet loss.
- the flushing and forwarding can be done exclusively by the BN if the BN pre-empts all other actions in the system (i.e. spin-locking). This can guarantee that flushing and forwarding will occur prior to any other forwarding. However, the BN should take great care with this approach since a lengthy pre-emption may have adverse effect on the systems health. In all cases, the solution is implementation specific.
- Maximum limits to the service duration should be administratively configured in the BN by defining a maximum size of the buffer as well as maximum duration of bp value as described in Sec 2.1.3.1. These limits should consider the local resources available to the BN. The limits should be considered non-negotiable values.
- the BCP is a control protocol used by the MN to request buffering services at the BN. It is a simple, reliable messaging system composed of request and answer signal pairs.
- the BCP may be defined as a new protocol or as extensions to existing protocols such as PANA, SIP, and Mobile IP (v4/v6) or defined as extensions to link layer protocols.
- Mobile IPv6 for example, it can be possible to define a new mobility option in Binding Update/Acknowledgement message exchange that carries the BCP in TLV format.
- PANA it is possible to define BCP AVP's that can be appended to the PUR/PUA message exchange. Other methods may be employed as long as the requirements of the BCP signaling can be accommodated. In all cases, delivery and encoding of BCP signals may become specific to each protocol that carries BCP.
- request signals are sent from the MN to the BN and answer signals are sent by BN to MN in response to a request signal.
- the BN should never generate a request signal.
- Request signals carry parameters regarding the request, and the answer signals contain result codes. Reliability is supported by using transmission timeouts, re-transmission, and error handling behavior.
- the BCP uses the following signal pairs.
- the BCP also creates service attributes (state information) within the BN. These attributes can include the following:
- the attributes can be allocated during the request phase as described in Sec 3.2.1.
- the values of the attributes are updated by the BN upon receiving valid request signals or other local events.
- the attributes lifetime is limited to the duration of the service. If a positive or negative EOS is met, the BN releases the resource occupied by these attributes.
- the BCP can divide the BN service into three phases. A buffering service must complete these phases in sequence.
- the service request phase is the initial phase used to establish a buffering service for an MN. It spans a single BReq[initial]/BAns[initial] signal exchange between MN and BN to negotiate the buffering requirements and determine if the BN can fulfill those requirements. If the BN is able to accommodate the MN then state information is allocated and the buffering of MN traffic starts immediately. The BN then sends a BAns[initial] to the MN with result code (rcode) indicating success. If the BN has made adjustments to hint values provided by the MN and is able to provide the service, the buffering service is also started with the BAns[initial] including an rcode indicating an error. If the BN is unable to provide service then no state information is allocated and the BN sends a BAns[initial] with the appropriate error code. The MN sends the following parameters in the initial BReq[initial].
- the MN can send this value to the BN.
- the BN can use this value for bp if it does not exceed a locally configured maximum limit, as described in Sec 2.2.3. If the value is below the maximum limit, the BN should set the rcode to indicate success in the BAns[initial]. If it exceeds the maximum limit, the BN can either deny the buffering request or use the maximum limit as the bp value. In either case, the BN should notify the MN of its decision by setting the rcode to indicate an error in the BAns[initial].
- the MN has the option of terminating the service if the BN uses a maximum value that the MN perceives to be unsuitable. In such a case, the MN can proceed immediately to the termination phase as described in Sec 3.3.3.
- the MN can suggest a bsz to be used by the BN during the service. This is possible since the MN may have prior knowledge of the application being used and consequently the expected traffic rate and channel conditions. In combination with the handoff period, the MN may be able to calculate a reasonable bsz needed to accommodate the classified traffic. However, the bsz provided by the MN is only a hint to the BN. The BN has the final authority on the actual bsz to be used based on locally available resources. If the BN is able to accommodate the bsz hinted by the MN, it may set the rcode indicating success in the BAns[initial].
- the BN may use the locally configured maximum limit and notify the MN of its decision by setting the rcode to indicate an error in the BAsn[initial].
- the MN has the option of terminating the service if the bsz issued by the BN is unsuitable. In such a case, the MN can proceed immediately to the termination phase as described in Sec 3.3.3.
- the MN may provide parameters regarding the type traffic that needs to be buffered. This is in case that the MN is interested in buffering only certain types of traffic (tc).
- the format of the tc parameter is implementation specific and the MN may be required having prior knowledge of this implementation.
- the FP sent by the MN dictates the policy that the BN should enforce with the buffered packets once EOS is met as described in Sec 2.1.3.
- Currently supported policy is to forward or drop the packets as described in Sec 2.1.4.
- a FP value in BReq[initial] specifying that the BN drop the buffered packets on any EOS may seem inappropriate since the service becomes meaningless.
- the MN decides to enforce two (2) different policies depending on the EOS conditions met as described in Sec 2.1.3.
- an MN may wish to drop all packets when time-limited buffering EOS is met, and forward all packets when explicit signaling EOS is met. In such a case, the default FP is set to drop all packets, and subsequent BReq[stop] that signals a positive EOS can carry a FP that forward all packets.
- the FP supplied in BReq[initial] may also be set to null
- the FP used may be a locally configured value.
- the buffering phase spans the period when traffic classification and buffering is occurring. This begins immediately after the BN responds with a BAns[initial] in the request phase indicating that buffering service is being provided, and ends when an EOS condition is met.
- the BN and MN can exchange one or more extension request (BReq[ext]/BAns[ext]). Each exchange completes an extension request negotiation. Extension request allows the MN to re-negotiate the attribute values that has been established during the request phase or previous extension request exchanges. It allows the buffering service to be extended. A BReq[stop]/BAns[stop] exchange may also be performed in this period to abort the buffering service. In such a case, the FP supplied with the BReq[stop] may enforce a policy of dropping all buffered packets.
- the MN synchronizes the signal exchange with the handoff period to make sure network connectivity is available during the signal exchange.
- the parameters provided by BReq[ext] are to be added to existing attribute values. Except for the FP, the resulting new values can be subject to the same limits and conditions imposed on the initial values in Sec 3.3.1.
- the MN sends the following parameters in every BReq[ext].
- the MN may notify the BN of additional handoff delay in the BReq[ext] signal.
- the handoff value provided in BReq[ext] is added to the existing handoff attribute value and subjected to the limits and conditions specified in Sec 3.3.1.1. This process is repeated for each new BReq[ext] received by the BN. In the case that the MN is not interested in adjusting this specific value, it may set this parameter to zero (0).
- the MN may provide a hint to the BN of how much more bsz is required for the extension request.
- the bsz value provided in BReq[ext] is added to the existing bsz attribute value and subjected to the limits and conditions specified in Sec 3.3.1.1. This process is repeated for each new BReq[ext] received by the BN.
- the MN may set this parameter to zero (0).
- the MN may use BReq[ext] to establish a new default FP for the current buffering service.
- the BN enforces the new FP when an EOS is met. If the FP supplied in BReq[ext] is null, then it is an indication to the BN to maintain the existing FP attribute value. If the existing attribute value is null, then the BN should set the FP attribute value to a locally configure value.
- the BReq[ext] can also be used to update the CoA of the MN to facilitate forwarding as described in Sec 2.1.5. Carrying the CoA on BReq[ext] is necessary in the case that the time-limited timeout pre-empts explicit signaling to meet a positive EOS. Having a CoA parameter in BReq[ext] also makes the BCP and BN architecturally independent of the circumstances in which it is being used. As an example, a BN residing on a MN, as shown in FIG. 3 can notify the BN of its previous CoA in case of ping-pong effects as discussed in Sec 2.1.6.
- Termination phase begins when an EOS is met, as described in Sec 2.1.3 and ends when all resource allocated for the buffering service is released to the system.
- the BN should follow the forwarding requirements described in Sec 2.1.5 and Sec 2.2.
- a BReq[stop]/BAns[stop] is exchanged between MN and BN to terminate a buffering service.
- the MN should synchronize with the handoff period to make sure that there is network connectivity during the signal exchange.
- An explicit BReq[stop] can also be used by the MN to abort the buffering service.
- the service is aborted when the MN signals a BReq[stop] with a FP that enforces the packets to be dropped.
- BReq[stop] has the following parameters.
- the MN and BN are on different IP links, and there is no tunnel between the BN and MN, then the BN also creates a new tunnel to the MN.
- the BN should enforce the FP supplied in BReq[stop]. If the FP supplied in BReq[stop] is null then the BN should enforce the existing FP attribute value.
- a FP, which specifies forwarding, should follow the forwarding requirements in Sec 2.2.
- BReq[stop] signal carries a CoA information, it should take override previous CoA information carried in BReq[ext] and should be used when forwarding the buffered packets.
- the BReq[stop] can also be used as a signal to establish an IP-IP tunnel in case the new CoA resides in the IP network different from it's home. Details are provided in Sec 2.1.5.
- the protocol flow shown in FIG. 4 provides a general sequence of the signal exchanges as it relates to the MN handoff, traffic classification and buffering.
- the variables o1 and o2 define the period where valid MN and BN can occur when network connectivity maybe present during the buffering phase.
- the BCP is a lock-step protocol that requires completion of an existing signal exchange before another signal exchange can be initiated. This simplifies the state transition in the BN and rigidity in re-transmission.
- BCP uses transmission timeouts and re-transmission to detect failure in signaling. Only request signals are re-transmitted. If an MN sends a request and does not receive an answer within a specified timeout period, it should re-transmit the request. An error condition occurs in the MN if no answer is received after a maximum number of re-transmission has occurred. Both the transmission timeout and maximum number of re-transmission should be a reasonable value to minimize overall delay. Answer signals sent by the BN should not be re-transmitted. The BN should respond with the same answer signal to any re-transmitted request. If connectivity with the MN is lost completely, the BN can rely on the hp value to terminate the buffering service.
- the BN should also rely on the sequence number associated with this signal to determine if the BReq[ext] it receives is a re-transmission.
- BAns[ext] signals sent by the BN must supply a matching sequence number equal to the sequence number in BReq[ext] associated with the answer. This is required since multiple BReq[ext]/BAns[ext] exchanges may occur.
- BReq[initial]/BAns[initial] and BReq[stop]/BAns[stop] signals does not require sequence number checks since these exchanges should only occur once during the beginning and end of the buffering service respectively. Signal validity can also be supplemented by checking the values of the sequence number.
- An MN may attempt to send a BReq[initial] to a network entity in both the existing network and the new network it is moving towards to discover the availability of buffering service.
- the MN can use the lack of response from the network entity to indicate which network does not provide buffering service.
- the lack of response should be defined as the time when the MN reaches the maximum number of re-transmission attempts without receiving an answer. If an MN receives no response from both networks then the service is not present. If the MN receives response from both networks then the MN should choose which network will provide the service and abort the request in the network it did not choose.
- the availability of the buffering service can be provided by existing mechanisms such as DNS or DHCP.
- the BCP does not provide inherent security. It relies on security provided by lower layer, IP layer (i.e., IPsec) or parent protocol that carries it, as described in Sec 3.8.
- IP layer i.e., IPsec
- parent protocol i.e., Sec 3.8.
- BN implementations may use of methods and facilities existing on a system.
- traffic classification can be done by using netfilter (iptables) or traffic control modules.
- Complex classification rules can be installed on a per flow basis using these tools.
- buffering can also be implemented using traffic control modules along with BN specific controls.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- [1] Moore, N., Choi J., Pentland Bret, “Tunnel Buffering for Mobile IPv6,” draft-moore-mobopts-tunnel-buffering-00.txt, July 2004;
- [3] Khalil, M., Akhtar H., Qaddoura E., Perkins C., Cerpa A., “Buffer Management for Mobile IP,” draft-mkhalil-mobileip-buffer-00.txt, October 1999
- [3] R. Koodli, “Fast Handovers for Mobile IPv6,” draft-ietf-mipshop-fast-mipv6-03.txt, October 2004;
- [4] Krishnamurthi G., Chalmers R., Perkins C., “Buffer Management for Smooth HandOvers in Mobile IPv6,” draft-krishnamurthi-mobileip-buffer6-00.txt, July 2000;
- [5] Chul-Ho Lee, Dongwook Lee, JongWon Kim, “Seamless MPEG-4 Video Streaming over Mobile IP-enabled Wireless LAN,” Network Research Workshop 2004/18th APAN meeting;
- [6] Perkins C., Wang K-Y., “Optimized smooth handoffs in Mobile IP,” Proceedings of IEEE Symposium on Computers and Communications, July 1999;
- [7] Pejman Roshan, Jonathan Leary, “802.11 Wireless LAN Fundamentals,” Cisco Press, ISBN 1587050773, December 2003;
- [8] Rosenberg J., Schulzrinne H., “An RTP Payload Format for Generic Forward Error Correction”, RFC 2733, December 1999;
- [9] Perkins C., Hodson O., “Options for Repair of Streaming Media,” RFC 2354, June 1998;
- [10] Bremen J., Wenger S., Sato N., et. Al., “Extended RTP Profile for RTCP-based Feedback (RTP/AVPF),” draft-ietf-avt-rtcp-feedback-11.txt, August 2004;
- [11] Reza Rejaie et al. RAP: An End-to-end Rate-based Congestion Control Mechanism for Real-time Streams in the Internet, March 1999.
-
- 1. Between an end-host and its access router as shown in
FIG. 1 ; - 2. Between an end-host and its access point. In this case, the buffering control protocol may be defined at either L2 or L3.
- 1. Between an end-host and its access router as shown in
BReq[initial]={id,bp,tc,bsz,p}
-
- id—MN Id used to uniquely identify the MN to the BN. This can be the source address or mac address of the MN.
- bp—Buffering Period
- tc—Application specific traffic to be classified and buffered
- bsz—Suggested buffer size to be allocated
- p—FP for EOS, valid values are drop, forward or drop with signal
- flag {m}—Request flags
- m—if set bsz is mandatory and cannot be negotiated
- BAns[initial]={id, bp, bsz, rcode}
- id—MN Id used to uniquely identify the MN to the BN. This can be the source address or mac address of the MN.
- bp—Buffering period for this service
- bsz—Buffer size allocated for this service
- rcode—Result code provided by BN
3.1.2 BReq[ext] and BAns[ext]
- id—MN Id used to uniquely identify the MN to the BN. This can be the source address or mac address of the MN.
BReq[ext]={id,seq,bp,bsz,p,coa}
-
- id—MN id sent in the BReq[initial]
- seq—Signal sequence number
- bp—Additional buffering period, maybe zero (0)
- bsz—Additional buffer size, maybe zero (0)
-
- coa—current CoA of the MN
BAns[ext]={id,seq,bp,bsz,rcode} - id—MN id sent in the BReq[initial]
- seq—Signal sequence number, must match BReq[ext]
- hp—New buffering period for this service
- bsz—New buffer size allocated for this service
- rcode—Result code provided by BN
3.1.3 BReq[stop] and BAns[stop]
- coa—current CoA of the MN
BReq[stop]={id,p,coa}
-
- id—MN id sent in the BReq[initial]
-
- coa—current CoA of the MN
BAns[stop]={id,rcode} - id—MN id sent in the BReq[initial]
- rcode—Result code provided by BN
3.2 Service Attributes
- coa—current CoA of the MN
Claims (36)
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/162,199 US8068460B2 (en) | 2005-07-14 | 2005-08-31 | Dynamic packet buffering system for mobile handoff |
JP2007513507A JP2008514034A (en) | 2005-07-14 | 2006-07-13 | Dynamic packet buffering system for mobile handoff |
EP06781278A EP1911239B1 (en) | 2005-07-14 | 2006-07-13 | Dynamic packet buffering system for mobile handoff |
CA2614856A CA2614856C (en) | 2005-07-14 | 2006-07-13 | Dynamic packet buffering system for mobile handoff |
PCT/JP2006/314311 WO2007007913A1 (en) | 2005-07-14 | 2006-07-13 | Dynamic packet buffering system for mobile handoff |
CN201510221333.1A CN104796951A (en) | 2005-07-14 | 2006-07-13 | Dynamic packet buffering system for mobile handoff |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US69895005P | 2005-07-14 | 2005-07-14 | |
US11/162,199 US8068460B2 (en) | 2005-07-14 | 2005-08-31 | Dynamic packet buffering system for mobile handoff |
Publications (2)
Publication Number | Publication Date |
---|---|
US20070014259A1 US20070014259A1 (en) | 2007-01-18 |
US8068460B2 true US8068460B2 (en) | 2011-11-29 |
Family
ID=37102121
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/162,199 Expired - Fee Related US8068460B2 (en) | 2005-07-14 | 2005-08-31 | Dynamic packet buffering system for mobile handoff |
Country Status (6)
Country | Link |
---|---|
US (1) | US8068460B2 (en) |
EP (1) | EP1911239B1 (en) |
JP (1) | JP2008514034A (en) |
CN (1) | CN104796951A (en) |
CA (1) | CA2614856C (en) |
WO (1) | WO2007007913A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100195567A1 (en) * | 2007-05-24 | 2010-08-05 | Jeanne Ludovic | Method of transmitting data packets |
US20110280214A1 (en) * | 2010-05-13 | 2011-11-17 | Ji Hoon Lee | Terminal for a content centric network and method of communication for a terminal and a hub in a content centric network |
US20130010665A1 (en) * | 2006-09-14 | 2013-01-10 | Kapil Chhabra | Ad-hoc network power save system and method |
US20140211611A1 (en) * | 2008-07-16 | 2014-07-31 | Huawei Technologies Co., Ltd. | Tunnel management method, tunnel management apparatus, and communications system |
US10075380B2 (en) * | 2017-01-23 | 2018-09-11 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Probabilistic metering |
Families Citing this family (50)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102325358A (en) * | 2002-11-04 | 2012-01-18 | 捷讯研究有限公司 | Method and apparatus for packet data service discovery |
EP1499131A1 (en) * | 2003-07-14 | 2005-01-19 | Deutsche Thomson-Brandt Gmbh | Method and apparatus for decoding a data stream in audio video streaming systems |
US7546125B2 (en) * | 2005-10-03 | 2009-06-09 | Divitas Networks, Inc. | Enhancing user experience during handoffs in wireless communication |
US7826424B2 (en) * | 2005-10-11 | 2010-11-02 | Toshiba America Research, Inc. | Packet loss prevention during handoff through managed buffer nodes architecture |
US8345645B2 (en) * | 2005-10-31 | 2013-01-01 | Avaya Inc. | WLAN access controller packet buffering |
US8401555B2 (en) * | 2005-11-30 | 2013-03-19 | Qualcomm Incorporated | Receiver status message management during handoff |
US8155650B2 (en) * | 2006-02-17 | 2012-04-10 | Cisco Technology, Inc. | Method and system for selective buffering |
US8391153B2 (en) | 2006-02-17 | 2013-03-05 | Cisco Technology, Inc. | Decoupling radio resource management from an access gateway |
CN101496387B (en) | 2006-03-06 | 2012-09-05 | 思科技术公司 | System and method for access authentication in a mobile wireless network |
US7480500B1 (en) | 2006-06-14 | 2009-01-20 | Divitas Networks, Inc. | Divitas protocol proxy and methods therefor |
US20080317241A1 (en) * | 2006-06-14 | 2008-12-25 | Derek Wang | Code-based echo cancellation |
US20080140767A1 (en) * | 2006-06-14 | 2008-06-12 | Prasad Rao | Divitas description protocol and methods therefor |
US20090016333A1 (en) * | 2006-06-14 | 2009-01-15 | Derek Wang | Content-based adaptive jitter handling |
US7565159B2 (en) * | 2006-06-14 | 2009-07-21 | Divitas Networks, Inc. | Methods and arrangement for implementing an active call handover by employing a switching component |
EP2050246A1 (en) * | 2006-08-09 | 2009-04-22 | Telefonaktiebolaget LM Ericsson (PUBL) | A method and apparatus for routing a packet in mobile ip system |
CN101141335A (en) * | 2006-09-07 | 2008-03-12 | 日电(中国)有限公司 | Subscriber terminal based fast skip zone switching method and equipment |
US7904086B2 (en) * | 2006-10-02 | 2011-03-08 | Board Of Regents, The University Of Texas System | Method and computer program for handoff of mobile devices between wireless systems |
US8792945B2 (en) * | 2006-10-31 | 2014-07-29 | Motorola Mobility Llc | Methods and devices for dual mode bidirectional audio communication |
US8817740B2 (en) * | 2006-10-31 | 2014-08-26 | Motorola Mobility Llc | Methods and devices of a queue controller for dual mode bidirectional audio communication |
US8380203B1 (en) | 2006-11-10 | 2013-02-19 | Marvell International Ltd. | Enhanced WLAN association for roaming |
JP4995927B2 (en) * | 2007-02-08 | 2012-08-08 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | How to reduce buffer overflow |
WO2008102564A1 (en) * | 2007-02-23 | 2008-08-28 | Panasonic Corporation | Network node and mobile terminal |
KR101336325B1 (en) * | 2007-03-16 | 2013-12-03 | 삼성전자주식회사 | Communication Apparatus and Method for Supporting Fast Handover Transparent to Mobile Station |
WO2008115125A2 (en) | 2007-03-21 | 2008-09-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Selective packet forwarding for lte mobility |
JP5127314B2 (en) * | 2007-06-19 | 2013-01-23 | キヤノン株式会社 | COMMUNICATION DEVICE, COMMUNICATION DEVICE CONTROL METHOD, AND PROGRAM |
US9030934B2 (en) * | 2007-09-07 | 2015-05-12 | Qualcomm Incorporated | Host-based quality of service for wireless communications |
EP2073597A1 (en) * | 2007-12-21 | 2009-06-24 | Telefonaktiebolaget L M Ericsson (Publ) | Technique for providing network access via multiple mobile platforms |
JP5002707B2 (en) * | 2008-03-27 | 2012-08-15 | 京セラ株式会社 | Wireless communication apparatus, communication apparatus, wireless communication method, and communication method |
CN102027798A (en) * | 2008-05-13 | 2011-04-20 | 三星电子株式会社 | Method and apparatus for providing voice call in mobile communication system and system thereof |
US20100222053A1 (en) * | 2009-02-27 | 2010-09-02 | Girisrinivasarao Athulurutirumala | Arrangement and methods for establishing a telecommunication connection based on a heuristic model |
US8547941B2 (en) * | 2009-04-16 | 2013-10-01 | Qualcomm Incorporated | Apparatus and method for improving WLAN spectrum efficiency and reducing interference by flow control |
US8532272B2 (en) * | 2009-10-21 | 2013-09-10 | Comcast Cable Communications, Llc | Service entry device |
US9515849B2 (en) * | 2009-12-22 | 2016-12-06 | At&T Intellectual Property I, L.P. | Method and apparatus for managing communication faults |
US8892632B2 (en) * | 2010-06-04 | 2014-11-18 | Microsoft Corporation | Client-server interaction frequency control |
US9794220B2 (en) | 2010-08-31 | 2017-10-17 | Comcast Cable Communications, Llc | Wireless extension of broadband access |
US8509188B1 (en) | 2011-02-16 | 2013-08-13 | Sprint Communications Company L.P. | Buffering user data in a core network interface for delivery over a wireless access network |
US20130003559A1 (en) * | 2011-06-30 | 2013-01-03 | Broadcom Corporation | Adaptive Power Savings for Aggregated Resources |
US8931016B2 (en) * | 2011-09-15 | 2015-01-06 | Verizon Patent And Licensing Inc. | Program handoff between devices and program network offloading |
WO2013131098A1 (en) * | 2012-03-02 | 2013-09-06 | Seven Networks, Inc. | Providing data to a mobile application accessible at a mobile device via different network connections without interruption and mobile devices which hands over connectivity from one network connection to another network connection without interruption in application data flow and methods therefor |
US9219541B2 (en) | 2012-06-13 | 2015-12-22 | All Purpose Networks LLC | Baseband data transmission and reception in an LTE wireless base station employing periodically scanning RF beam forming techniques |
US8565689B1 (en) | 2012-06-13 | 2013-10-22 | All Purpose Networks LLC | Optimized broadband wireless network performance through base station application server |
US9882950B2 (en) | 2012-06-13 | 2018-01-30 | All Purpose Networks LLC | Methods and systems of an all purpose broadband network |
US9503927B2 (en) | 2012-06-13 | 2016-11-22 | All Purpose Networks LLC | Multiple-use wireless network |
WO2015148816A1 (en) * | 2014-03-28 | 2015-10-01 | All Purpose Networks LLC | Methods and systems of an all purpose broadband network |
US11044639B2 (en) * | 2016-04-21 | 2021-06-22 | Qualcomm Incorporated | Techniques for transmission control protocol aware handover type determination |
US10827019B2 (en) | 2018-01-08 | 2020-11-03 | All Purpose Networks, Inc. | Publish-subscribe broker network overlay system |
US11026090B2 (en) | 2018-01-08 | 2021-06-01 | All Purpose Networks, Inc. | Internet of things system with efficient and secure communications network |
DE112018007637T5 (en) * | 2018-09-28 | 2021-04-29 | Intel Corporation | Error message in connection extension devices |
CN110233889B (en) * | 2019-06-11 | 2021-09-14 | 常熟理工学院 | Network data communication implementation method based on cache mechanism |
US11509642B2 (en) * | 2019-08-21 | 2022-11-22 | Truist Bank | Location-based mobile device authentication |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1094647A2 (en) | 1999-10-18 | 2001-04-25 | Nortel Networks Limited | Buffer management for mobile internet protocol |
US6651105B1 (en) * | 1998-11-12 | 2003-11-18 | International Business Machines Corporation | Method for seamless networking support for mobile devices using serial communications |
US7936719B2 (en) * | 2006-04-20 | 2011-05-03 | Toshiba America Research, Inc. | Packet loss prevention during handoff using packet copy-and-forward |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI109503B (en) * | 1997-04-15 | 2002-08-15 | Nokia Corp | Prevention of packet loss during handover in a packet-based telecommunications network and handover procedure |
JP3442257B2 (en) * | 1997-05-06 | 2003-09-02 | 日本電信電話株式会社 | Packet communication method |
JPWO2003071749A1 (en) * | 2002-02-20 | 2005-06-16 | 三菱電機株式会社 | Mobile network |
ES2291853T3 (en) * | 2004-02-16 | 2008-03-01 | Telefonaktiebolaget Lm Ericsson (Publ) | MANAGEMENT OF ADDRESSES IN ENVIRONMENTS BASED ON MOBILE IP (MOBILE IP). |
-
2005
- 2005-08-31 US US11/162,199 patent/US8068460B2/en not_active Expired - Fee Related
-
2006
- 2006-07-13 JP JP2007513507A patent/JP2008514034A/en active Pending
- 2006-07-13 WO PCT/JP2006/314311 patent/WO2007007913A1/en active Application Filing
- 2006-07-13 CA CA2614856A patent/CA2614856C/en not_active Expired - Fee Related
- 2006-07-13 CN CN201510221333.1A patent/CN104796951A/en active Pending
- 2006-07-13 EP EP06781278A patent/EP1911239B1/en not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6651105B1 (en) * | 1998-11-12 | 2003-11-18 | International Business Machines Corporation | Method for seamless networking support for mobile devices using serial communications |
EP1094647A2 (en) | 1999-10-18 | 2001-04-25 | Nortel Networks Limited | Buffer management for mobile internet protocol |
US7936719B2 (en) * | 2006-04-20 | 2011-05-03 | Toshiba America Research, Inc. | Packet loss prevention during handoff using packet copy-and-forward |
Non-Patent Citations (15)
Title |
---|
C. Perkins, "Optimized smooth handoffs in Mobile IP," Proceedings of IEEE Symposium on Computers and Communications, Jul. 1999, p. 1-7, USA. |
C. Perkins, "Options for Repair of Streaming Media", Jun. 1998, p. 1-10, The Internet Society, USA. |
Chul-Ho Lee, Seamless MPEG-4 Video Streaming over Mobile IP-enabled Wireless LAN, p. 1-9, Korea. |
D. Jeong et al., "The Performance Analysis of QoS Provisioning Method w/Buffering & CAC in the Multimedia Wireless Internet," IEEE Vehicular Tech. Conf., NY, NY Oct. 7, 2001. |
European Office Action dated Apr. 20, 2010, issued in corresponding European Patent Application No. 06781278.4. |
G. Krishnamurthi, "Buffer Management for Smooth HandOvers in Mobile IPv6", Jul. 2000, p. 1-27, The Internet Society, USA. |
G. Krishnamurthi, Buffer Management for Smooth Handovers in IPv6, IETF Standard Working Draft, Internet Engineering Task Force, IETF, CH, Feb. 13, 2001. |
J. Ott, Extended RTP Profile for RTCP-based Feedback, Aug. 10, 2004, p. 1-51, Internet Draft, USA. |
J. Rosenberg, An RTP Payload Format for Generic Forward Error Correction, Dec. 1999, p. 1-25, USA. |
M. Khalil, "Buffer Management for Mobile IP," IETF Standard Working Draft, Internet Engineering Task Force, IETF, CH Oct. 1999. |
M. Khalil, "Buffer Management for Mobile IP," Internet-Draft, Oct. 1999, p. 1-20, The Internet Society, USA. |
N. Monash, Tunnel Buffering for Mobile IPv6, Jul. 9, 2004, p. 1-11, Internet Draft, USA. |
R. Koodli, Fast Handovers for Mobile IPv6, Oct. 25, 2004, p. 1-53, Internet Draft, USA. |
R. Rejaie, "RAP: An End-to-end Rate-based Congestion Control Mechanism for Real-time Streams in the Internet", Mar. 1999, p. 1-27, USA. |
Wei-Min Yao et al., "An enhanced buffer management scheme for fast handover protocol," Distributed Computing Systems Workshops. 2004. Proceedings. IEEE, Mar. 23, 2004, pp. 896-902. |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130010665A1 (en) * | 2006-09-14 | 2013-01-10 | Kapil Chhabra | Ad-hoc network power save system and method |
US8830891B2 (en) * | 2006-09-14 | 2014-09-09 | Marvell World Trade Ltd. | Ad-hoc network power save system and method |
US20100195567A1 (en) * | 2007-05-24 | 2010-08-05 | Jeanne Ludovic | Method of transmitting data packets |
US8638785B2 (en) * | 2007-05-24 | 2014-01-28 | Thomson Licensing | Method of transmitting data packets |
US20140211611A1 (en) * | 2008-07-16 | 2014-07-31 | Huawei Technologies Co., Ltd. | Tunnel management method, tunnel management apparatus, and communications system |
US9235462B2 (en) * | 2008-07-16 | 2016-01-12 | Huawei Technologies Co., Ltd. | Tunnel management method, tunnel management apparatus, and communications system |
US20110280214A1 (en) * | 2010-05-13 | 2011-11-17 | Ji Hoon Lee | Terminal for a content centric network and method of communication for a terminal and a hub in a content centric network |
US9756535B2 (en) * | 2010-05-13 | 2017-09-05 | Samsung Electronis Co., Ltd. | Terminal for a content centric network and method of communication for a terminal and a hub in a content centric network |
US10075380B2 (en) * | 2017-01-23 | 2018-09-11 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Probabilistic metering |
Also Published As
Publication number | Publication date |
---|---|
WO2007007913A1 (en) | 2007-01-18 |
CA2614856A1 (en) | 2007-01-18 |
EP1911239A1 (en) | 2008-04-16 |
CA2614856C (en) | 2015-04-14 |
US20070014259A1 (en) | 2007-01-18 |
JP2008514034A (en) | 2008-05-01 |
EP1911239B1 (en) | 2012-03-28 |
CN104796951A (en) | 2015-07-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8068460B2 (en) | Dynamic packet buffering system for mobile handoff | |
US7936719B2 (en) | Packet loss prevention during handoff using packet copy-and-forward | |
US8165088B2 (en) | MIH protocol state machine | |
US7542481B2 (en) | Connection optimization for communications in multiple access environment | |
US8792420B2 (en) | Multimedia communication using co-located care of address for bearer traffic | |
US20120051321A1 (en) | Method for seamless ip session continuity for multi-mode mobile stations | |
EP2225837A1 (en) | Seamless service method controlled by user terminal | |
US8139603B2 (en) | Architecture for multiple MIH users | |
Georgiades et al. | AAA context transfer for seamless and secure multimedia services over all-IP infrastructures | |
Dutta et al. | Dynamic buffering control scheme for mobile handoff | |
Bauer et al. | The UMTS base station router | |
CN101006704A (en) | Dynamic packet buffering system for mobile handoff | |
Barooah et al. | An architectural framework for seamless handoff between IEEE 802.11 and UMTS networks | |
Nursimloo et al. | Integrating fast mobile IPv6 and SIP in 4G network for real-time mobility | |
Rajkumar et al. | Seamless SIP‐based VoIP in disparate wireless systems and networks | |
Banerjee et al. | SIP-Based Mobility Management and Its Performance Evaluation | |
Larsen | Mobility schemes for future networks based on the IMS |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: TOSHIBA AMERICA RESEARCH, INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FAJARDO, VICTOR;OBA, YOSHIHIRO;TANIUCHI, KENICHI;AND OTHERS;REEL/FRAME:021181/0797;SIGNING DATES FROM 20060118 TO 20060223 Owner name: TELCORDIA TECHNOLOGIES, INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FAJARDO, VICTOR;OBA, YOSHIHIRO;TANIUCHI, KENICHI;AND OTHERS;REEL/FRAME:021181/0797;SIGNING DATES FROM 20060118 TO 20060223 Owner name: TOSHIBA AMERICA RESEARCH, INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FAJARDO, VICTOR;OBA, YOSHIHIRO;TANIUCHI, KENICHI;AND OTHERS;SIGNING DATES FROM 20060118 TO 20060223;REEL/FRAME:021181/0797 Owner name: TELCORDIA TECHNOLOGIES, INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FAJARDO, VICTOR;OBA, YOSHIHIRO;TANIUCHI, KENICHI;AND OTHERS;SIGNING DATES FROM 20060118 TO 20060223;REEL/FRAME:021181/0797 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
CC | Certificate of correction | ||
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20191129 |
|
AS | Assignment |
Owner name: TELCORDIA LEGACY INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TOSHIBA AMERICA RESEARCH, INC.;REEL/FRAME:055403/0165 Effective date: 20210217 |