Source: https://patents.google.com/patent/US9749838B2/en
Timestamp: 2018-05-25 02:15:02
Document Index: 329497964

Matched Legal Cases: ['Application No. 61', 'application No. 12', 'Application No. 201280051162', 'Application No. 2014', 'Application No. 2016122064', 'Application No, 201280051152']

US9749838B2 - PMIP protocol enhancement - Google Patents
PMIP protocol enhancement Download PDF
US9749838B2
US9749838B2 US13508544 US201213508544A US9749838B2 US 9749838 B2 US9749838 B2 US 9749838B2 US 13508544 US13508544 US 13508544 US 201213508544 A US201213508544 A US 201213508544A US 9749838 B2 US9749838 B2 US 9749838B2
US13508544
US20130044682A1 (en )
Example embodiments presented herein are directed towards determining a Proxy Mobile Internet Protocol version 6 (PIMPv6) control plane used by a network node peer in an Internet Protocol version 4 (IPv4) transport network. The example embodiments provide a mechanism in PMIP protocol stack, to allow a Mobility Access Gateway/Local Mobility Anchor (MAG/LMA) node such as SGW (which may be supporting both PMIP draft and PMIP RFC) to decide which PMIP protocol stack shall be used to communicate to the peer node, i.e. LMA/MAG.
This application claims the benefit of U.S. Provisional Application No. 61/524,522, filed on Aug. 17, 2011. This application is also a National Stage application under 35 U.S.C. 371 of International Application No. PCT/EP2012/057626, filed on Apr. 26, 2012.
The example embodiments are directed towards improving PMIP protocol usage. Specifically, some of the example embodiments are directed towards providing a network node the decision of which PMIP protocol shall be used in network communications.
Proxy Mobile Internet Protocol version 6 (PMIPv6) is a network-based mobility management protocol standardized by IETF. PMIPv6 is a protocol for building a common and access technology independent of mobile core networks, accommodating various access technologies such as WiMAX, 3GPP, 3GPP2 and WLAN based access architectures.
At least one example object of the example embodiments presented herein is to improve PMIPv6 communications. The concept of the example embodiments presented herein is to provide a mechanism in PMIP protocol stack, to allow a MAG node such as SGW (which may be supporting both PMIP draft and PMIP RFC) or a LMA to decide which PMIP protocol stack shall be used to communicate to the peer node, i.e. LMA/MAG. Some of the example embodiments presented herein may be directed towards solving backward incompatibility issues between the PMIP RFC and the PMIP Draft.
The example embodiments may comprise a mechanism for a supporting dual PMIP protocol (PMIP RFC or PMIP draft) stack node, e.g. MAG/LMA, when the transportation network is IPv4 network and it initiates communication towards a peer node, e.g. sending Proxy Binding Update message. The mechanism may comprise sending the message in two formats in the very first communication with the peer node or it doesn't know which PMIP protocol the peer node supports, one is in light of PMIP draft, i.e. PMIPv6 message/IPv6/with IPv4 or IPv4-UDP encapsulation and the other is in line with PMIP RFC, i.e. PMIPv6/UDP/IPv4. Therefore, if the peer node supports one PMIP protocol stack, it will only be able to answer one of the messages; and if the peer node supports both PMIP protocol stacks, the node may respond solely to the RFC version messages. By above mechanism, either the PMIP draft or PMIP RFC protocol stack may be selected for the rest communication.
Accordingly, some of the example embodiments may be directed towards a method in a first network peer node for determining a PMIPv6 control plane used by a second network peer node. The first and second network peer nodes are in an Internet Protocol version 4 (IPv4) transport network. The method comprises sending, to the second network peer node, at least one communication message in at least one control plane format. The method further comprises receiving at least one communication response with respect to the at least one communication message. The method also comprises determining a version of the PMIPv6 control plane which is utilized by the second network peer node based on the at least one communication response.
Some of the example embodiments may be directed towards a first network peer node for determining a PMIPv6 control plane used by a second network peer node. The first and second network peer nodes are in an IPv4 transport network. The first network peer node comprises transmitting circuitry configured to send, to the second network peer node, at least one communication message in at least one control plane format. The first network peer node further comprises receiving circuitry configured to receive at least one communication response with respect to the at least one communication message. The first network peer node also comprises processing circuitry configured to determine a version of the PMIPv6 control plane which is utilized by the second network peer node based on the at least one communication response.
FIG. 5 is a flow diagram depicting example operations of the network node of FIG. 4.
As a means of explaining the example embodiments presented herein, a problem will first be identified and discussed. 3GPP CT4 has agreed to update the PMIP C-plane protocol stack of TS29.275 to align RFC as for Rel-9/onward. Although the reference to the IETF document of Rel-9 has already been updated to RFC5844 from the IETF Draft, “IPv4 Support for Proxy Mobile IPv6”, draft-ietf-netlmm-pmip6-ipv4-support-17. However, the change for the C-Plane protocol stack has not been reflected.
At the same time CT4 realized that the RFC was not backward compatible to the draft when using PMIPv6 over an IPv4 transport network. With the draft version, NAT-traversal was recommended where the UDP encapsulation is optional depending on if an on-path NAT has been detected or not. With the PMIP RFC, UDP encapsulation becomes mandatory and the inner IPv6 header is removed. Thus, a draft version PMIP node cannot communicate with a RFC version PMIP node. Furthermore, a draft version based PMIP operator cannot keep the draft version PMIP node forever as the draft version PMIP protocol stack is not supported by IETF anymore. However, the interworking issue also gives a problem for a draft version based PMIP network migrating to a RFC based PMIP network. Thus, some mechanisms or backward compatible way to update the specification from Rel-8 to Rel-9/onward was required.
A DNS based solution comprised in the 3GPP CT4 contribution C4-111205 was proposed by NTTDOCOMO, to enhance DNS procedures for GW selection, where new Service Parameters “x-3GPP-sgw:x-s5-pmip2”, “x-3GPP-sgw:x-s8-pmip2”, “x-3GPP-pgw:x-s5-pmip2” were introduced to indicate the RFC style PMIP Control Plane A capability while following existing “Service Parameters” “x-3GPP-sgw:x-s8-pmip”, “x-3GPP-sgw:x-s5-pmip”, “x-3GPP-pgw:x-s5-pmip” which are reflecting draft style PMIP Control Plane capability. By introducing the above new Service Parameter, the MME/S4-SGSN is able to select SGW/PGW with the same style of the PMIP protocol stack.
Below various methods for improving PMIP communications will be discussed.
Migration Path—Non-Roaming Case
Migration paths to upgrade those PMIP draft based nodes, e.g. SGW/PGW/ePDG, to PMIP RFC based will now be discussed.
Alternative 1: Upgrade all PMIP nodes to RFC based PMIP protocol stack within one night
No impact on non-PMIP nodes
Quick migration path (One step migration)
Limited system downtime
All nodes have to be upgraded together
As shown in FIG. 1, LMA 1 and MAG 1 are draft based PMIP nodes. Step 1 of the migration path is to add LMA 2 and MAG 2 which is dual stack supported. Both MAGs can communicate with the two LMAs without any problem.
Step 2 of the migration path, illustrated in FIG. 2, is to add LMA3 and MAG3 which is RFC stack supported when the draft based PMIP nodes has been removed (or upgraded) completely. This is to avoid the interworking and mobility problem between LMA1/MAG1 and LMA3/MAG3.
Similar to step 1, to avoid communication problems at the very first time, an indicator may be needed at the MAGs before sending the very first PMIP message to a specific LMA. This indicator may also need to be forwarded to the target system at mobility procedure. In this step the indicator shall inform the MAG2 either RFC protocol stack shall be applied or any protocol stack shall be applied.
All the new PMIP nodes and old PMIP nodes can communicate to each without another problem.
The PMIP node upgrade can be taken one by one
Longer migration path
Two steps migration
In step 1, new developed PMIP node has to support both draft based and RFC based protocol stack simultaneously.
As shown in FIG. 3, LMA 1 and MAG 1 are draft based PMIP nodes. LMA 2 and MAG 2 are the new PMIP node which is RFC based only. There is no communication between LMA1 and MAG2 or between LMA2 and MAG1 due the incompatible issue of the supported PMIP protocol stack.
New PMIP node is not required to support PMIP draft which is ultimately shall be removed from 3GPP.
Two separated network to maintain.
No load sharing, interworking and mobility between the two networks.
Alternative 1 is an easy and quick solution. It also does not require any standardization work. Alternative 3 is unlikely to happen due to the interworking and mobility issues and the maintenance work of two networks at same time.
Solution 1: Local configuration in MAG2
In migration step 1, the MAG2 shall be configured with draft version enabled.
In migration step 2, the MAG2 shall be re-configured with RFC version enabled.
No standardization impact
No impacts on any non-PMIP nodes
Network management cost for re-configuration in SGW
Solution 2: A new GTP indicator sent by MME
Before migration step 1, all MMEs in the network have to be upgraded in order to support the new GTP indicator.
In migration step 1, the MME sends the new “draft version shall be used” indicator with to MAG2 at Create Session Request message.
In migration step 2, the MME sends the new “RFC version shall be used” indicator with to MAG2 at Create Session Request message.
No re-configuration in MAGs
Standardization impacts on GTP
Network management cost for re-configuration in MME
Solution 3: A new GTP indicator sent by MME, plus a new DNS name paring function
In migration step 1, only “draft version PMIP” shall be selected at MME DNS paring procedure. And the MME sends the new “draft version shall be used” indicator with to MAG2 at Create Session Request message.
Before migration step 2, new DNS configuration for the new PMIP DNS name.
In migration step 2, only “RFC version PMIP” shall be selected at the MME DNS paring procedure. And the MME sends the new “RFC version shall be used” indicator with to MAG2 at Create Session Request message.
No re-configuration in MAGs.
Standardization impacts on GTP.
New MME DNS paring procedure which may not be backward compatible.
Network management cost for re-configuration in MME and DNS.
Solution 4: Same as solution 3, but with two new DNS names in a migration network.
With this solution, the current DNS name is unchanged in the standards. Two new PMIP DNS names are added for S5 interface: s5-pmip-rfc and s5-pmip-draft.
The two new PMIP DNS names are only used within the migration network. This can avoid any impacts on existing R8/R9/R10 MME implementations.
Introduction to the Example Embodiments
Alternative 2 is very possible as it provides a smooth migration path. However, a migration solution may be needed. This is because the MAG 2 needs to know which PMIP version shall be applied before sending a PMIP message to a LMA. It could use a DNS based solution, where new Service Parameters are introduced to allow the MME to select a set of SGW/PGW nodes which are supporting the same PMIP protocol stack, however in order to support roaming and inter-SGW mobility procedures, inter 3GPP and non-3GPP procedures, the complete DNS solution needs to update many protocols, e.g. DNS/GTP/Diameter protocol, and this has an impact on many interfaces S11/S4/S3/S10/S1 S6a/S6d/SWx. More importantly is the fact that in order to support PMIP based roaming, the MME (even if it is located in a serving network where only one PMIP RFC is deployed but having a roaming agreement with problematic Home PLMN where both PMIP stacks are deployed) has to support new PMIP naming and has to support a new PMIP protocol stack IE in GTPv2, this is not appropriate. On the other hand, supporting dual stacks as an intermediate step during migration cannot be avoided, therefore another beneficial solution, which is purely enhancement on PMIP protocol stack, could be utilized.
Some of the example embodiments may comprise updates to LMA related procedures. When a LMA node supports both PMIP protocol stacks as specified above and the IPv4 is used in transportation network, and it receives the PMIP message in two formats from the same MAG, the LMA node may only send the response message in RFC format.
Example Updates on Heartbeat Mechanisms
Some example embodiments may be directed towards an upgrade mechanism in a PMIP tunnel management procedure. When a MAG or LMA node supports both PMIP protocol stacks as specified above and the IPv4 is used in transportation network, in case of software upgrades, e.g. upgrade to the RFC based PMIP version, the MAG or LMA node may increase the Restart Counter which will trigger the Heartbeat mechanism to inform the peer node what PMIP version it is supporting.
FIG. 4 illustrates an example of a network node (e.g., a MAG, LMA, and/or peer node) which may incorporate some of the example embodiments discussed herein. The network node 14 may comprise any number of communication ports or circuitry, for example receiving circuitry 20 and transmitting circuitry 24. The communication ports or circuitry may be configured to receive and transmit any form of communications data or instructions. It should be appreciated that the network node 14 may alternatively comprise a single transceiver port or circuitry. It should further be appreciated that the communication or transceiver port or circuitry may be in the form of any input/output communications port or circuitry known in the art.
The network node 14 may also comprise processing circuitry 22 that may be configured to establish a plurality of optical routes based on information received in a SSL 11. It should be appreciated that the processing circuitry 22 may be any suitable type of computation unit, e.g. a microprocessor, digital signal processor (DSP), field programmable gate array (FPGA), or application specific integrated circuit (ASIC). It should also be appreciated that the processing circuitry 22 need not be comprised as a single unit. The processing circuitry 22 may be comprised as any number of units or circuitry.
FIG. 5 is a flow diagram depicting example operations of a first network peer node, such as the network node of FIG. 4. The example flow of operations is directed towards a method in the first network peer node for determining a PMIPv6 control plane used by a second network peer node. The first and second network peer nodes are in an IPv4 transport network. The first and second network peer nodes may be MAG/LMA nodes such as the MAG/LMA nodes described in FIGS. 1-3. It should be appreciated that according to some of the example embodiments, the LMA node may be a PGW. According to some of the example embodiments, the MAG node may be a SGW, a Evolved Packet Data Gateway (ePDG), a HRPD Serving Gateway (HS GW), and/or a Broadband Network Gateway (BNG).
According to some of the example embodiments, the first network peer node is a MAG node and the second network peer node is a LMA node. In such example embodiments, the at least one communication may be a Heartbeat message or a proxy binding update request.
According to some of the example embodiments, the first network peer node is a LMA node and the second network peer node is a MAG node. In such example embodiments, the at least one communication is a Heartbeat message.
According to some of the example embodiments, the at least one communication message may be a first communication message of a first control type. If a response from the second network peer node is not received within a period of time, the at least one communication response is a first communication response. The first communication response is a first internal notification that a second communication message of a second control plane type needs to be sent. For example, not receiving a response from the second network peer node may be the result of the second network peer node not supporting the first control type in which the first communication message was sent. The receipt of the first internal notification may be based on user programmable rules within the first network peer node. It should be appreciated that the above scenario may be used to describe example operations 54, 58, 62 and 64.
Thus, according to some of the example embodiments, the first network peer node may send 54 the second communication message of the second control plane type. The transmitting circuitry 24 may send the second communication message of the second control plane type.
The first network peer node further determines 60 a version of the PMIPv6 control plane which is utilized by the second network peer node based on the at least one communication response. The processing circuitry 22 is configured to determine the version of the PMIPv6 control plane which is utilized by the second network peer node based on the at least one communication response.
According to some of the example embodiments, if a response from the second network peer node is not received within the predetermined period of time, the second communication response is a second internal notification that indicates communication with the second network node is not possible. Thus, the determining 60 may further comprise determining 62 the PIMPv6 control plane to be a null value. The processing circuitry 22 may be configured to determine the PIMPv6 control plane to be a null value.
According to some of the example embodiments, if the second communication response is received from the second network peer node, the determining 60 may further comprise determining 64 the PIMPv6 control plane value to be the second control type (e.g., the control type of the second communication message). The processing circuitry 22 is configured to determine the PIMPv6 control plane value to be the second control type.
According to some of the example embodiments, if a plurality of communication responses are received from the second network peer node (e.g., after a plurality or two communication messages are transmitted), the determining 60 may further comprise determining 68 the PIMPv6 control plane value to be a default control plane format. According to some of the example embodiments, the default control plane format value may be control plane A. The processing circuitry 22 may be configured to determine the PIMPv6 control plane value to be the default control plane format.
b. The example embodiments should be able to minimize any possible system downtime.
c. The example embodiments should minimize the impact to other network elements, e.g. MME/HSS, which are based on complete different protocol stacks.
Some of the example embodiments may comprise a method in a network node for PMIP protocol enhancement, wherein the network node may be in an IPv4 network. The method may comprise the steps of initiating a communication towards a peer node; and transmitting, to the peer node, a PMIP message in two formats. The example embodiments described above may further comprise transmitting the PMIP message in a PMIP draft and PMIP RFC format.
1. A method in a first network peer node for determining a Proxy Mobile Internet Protocol version 6 (PMIPv6) control plane used by a second network peer node, the first and second network peer nodes being in an Internet Protocol version 4 (IPv4) transport network, the method comprising:
sending, to the second network peer node, a first communication message in a first control plane format, said first control plane format being one of: a control plane format according to Request For Comment (RFC) 5844 (RFC Control Plane Format) and a control plane format according to a draft of RFC 5844 (Draft RFC Control Plane Format);
obtaining first information with respect to the first communication message, the first information indicating one of: 1) that the second network peer responded to the first communication message by transmitting a responsive communication message in said first control plane format and 2) that the second network node did not respond to the first communication message by transmitting a responsive communication message in said first control plane format; and
determining, using said obtained first information, whether the second network peer node is: a) utilizing a first version of the PMIPv6 control plane or a second version of the PMIPv6 control plane or b) not utilizing either the first version or the second version of the PMIPv6 control plane, wherein the first version of the PMIPv6 control plane is a version corresponding to RFC 5844 and the second version of the PMIPv6 control plane is a version corresponding to a draft of RFC 5844.
the first network peer node is a Mobile Access Gateway (MAG) node,
the second network peer node is a Local Mobility Anchor (LMA) node, and
the communication message is a Heartbeat message or a proxy binding update request.
the first network peer node is a Local Mobility Anchor (LMA) node,
the second network peer node is a Mobile Access Gateway (MAG) node, and
the communication message is a Heartbeat message.
the obtained first information indicates that the second network node did not respond to the first communication message by transmitting a responsive communication message in said first control plane format, and
the method further comprises sending, to the second network peer node, a second communication message in a second control plane format that is different than the first control plane format, wherein
the sending of the second communication message is performed as a result of obtaining said first information indicating that the second network node did not respond to the first communication message by transmitting a responsive communication message in said first control plane format, and
said second control plane format being one of: an RFC Control Plane Format and a Draft RFC Control Plane Format.
after sending the second communication message, obtaining second information with respect to the second communication message, the second information indicating one of: 1) that the second network peer responded to the second communication message by transmitting a responsive communication message in said second control plane format and 2) that the second network node did not respond to the second communication message by transmitting a responsive communication message in said second control plane format; and
determining, using said obtained second information, whether the second network peer node is: a) utilizing a first version of the PMIPv6 control plane or a second version of the PMIPv6 control plane or b) not utilizing either the first version or the second version of the PMIPv6 control plane, wherein the first version of the PMIPv6 control plane is a version corresponding to RFC 5844 and the second version of the PMIPv6 control plane is a version corresponding to a draft of RFC 5844.
the obtained second information indicates that the second network node did not respond to the first communication message by transmitting a responsive communication message in said second control plane format, and
as a result of said second information indicating that the second network node did not respond to the first communication message by transmitting a responsive communication message in said second control plane format, it is determined that the second network peer node is not utilizing either the first version or the second version of the PMIPv6 control plane.
said second control plane format is said Draft RFC Control Plane Format,
the obtained second information indicates that the second network peer responded to the second communication message by transmitting a responsive communication message in said second control plane format, and
as a result of said second information indicating that that the second network peer responded to the second communication message by transmitting a responsive communication message in said second control plane format, it is determined that the second network peer node is utilizing the second version of the PMIPv6 control plane.
the obtained second information indicates that the second network peer responded to the first communication message by transmitting a responsive communication message in said first control plane format,
as a result of said first information indicating that that the second network peer responded to the first communication message by transmitting a responsive communication message in said first control plane format, it is determined that the second network peer node is utilizing one of the first version of the PMIPv6 control plane and the second version of the PMIPv6 control plane.
sending, to the second network peer node, a second communication message in a second control plane format, said second control plane format being a control plane format according the RFC Control Plane Format, wherein
said first control plane format is a control plane format according to the Draft RFC Control Plane Format, and
the second communication message is sent prior to obtaining said first information.
10. The method of claim 9, wherein if only one communication response is received from the second network peer node, the determining further comprises determining the PIMPv6 control plane value to be the control plane format of the received communication response.
11. The method of claim 9, wherein if a plurality of communication responses are received from the second network peer node, the determining further comprises determining the PIMPv6 control plane value to be a default control plane format.
12. The method of claim 11, wherein the default control plane format is control plane A.
13. The method of claim 9, wherein if no responses from the second network peer node are received within a predetermined period of time, the communication response is an internal notification that indicates communication with the second network peer node is not possible, and the determining further comprises determining the PIMPv6 control plane is a null value.
14. The method of claim 4, wherein the first control plane format is control plane A and the second control plane format is control plane C.
15. A first network peer node for determining a Proxy Mobile Internet Protocol version 6 (PMIPv6) control plane used by a second network peer node, the first and second network peer nodes being in an Internet Protocol version 4 (IP4) transport network, the first network peer node comprising:
transmitting circuitry;
receiving circuitry; and
processing circuitry, the processing circuitry being configured to:
employ the transmitting circuitry to send, to the second network peer node, a first communication message in a first control plane format, said first control plane format being one of: a control plane format according to Request For Comment (RFC) 5844 (RFC Control Plane Format) and a control plane format according to a draft of RFC 5844 (Draft RFC Control Plane Format);
obtain information with respect to the first communication message, the information indicating one of: 1) that the second network peer responded to the first communication message by transmitting a responsive communication message in said first control plane format and 2) that the second network node did not respond to the first communication message by transmitting a responsive communication message in said first control plane format; and
16. The first network peer node of claim 15, wherein
the first communication message is a Heartbeat message or a proxy binding update request.
17. The first network peer node of claim 15, wherein the first network peer node is a Local Mobility Anchor, LMA, node and the second network peer node is a Mobile Access Gateway, MAG, node and the first communication message is a Heartbeat message.
18. The first network peer node of claim 15, wherein
the processing circuitry is further configured to employ the transmitting circuitry to send, to the second network peer node, a second communication message in a second control plane format that is different than the first control plane format, wherein
the sending of the second communication message is performed as a result of said first information indicating that the second network node did not respond to the first communication message by transmitting a responsive communication message in said first control plane format, and
19. The first network peer node of claim 18, wherein
the processing circuitry is configured such that, after sending the second communication message, the processing circuitry determines, using second information related to the second communication message, whether the second network peer node is: a) utilizing a first version of the PMIPv6 control plane or a second version of the PMIPv6 control plane or b) not utilizing either the first version or the second version of the PMIPv6 control plane, wherein the first version of the PMIPv6 control plane is a version corresponding to RFC 5844 and the second version of the PMIPv6 control plane is a version corresponding to a draft of RFC 5844, and
the second information indicates one of: 1) that the second network peer responded to the second communication message by transmitting a responsive communication message in said second control plane format and 2) that the second network node did not respond to the second communication message by transmitting a responsive communication message in said second control plane format.
20. The first network peer node of claim 19, wherein
the second information indicates that the second network node did not respond to the first communication message by transmitting a responsive communication message in said second control plane format, and
the processing circuitry is configured such that, as a result of said second information indicating that the second network node did not respond to the first communication message by transmitting a responsive communication message in said second control plane format, the processing circuitry determines that the second network peer node is not utilizing either the first version or the second version of the PMIPv6 control plane.
21. The first network peer node of claim 19, wherein
the processing circuitry is configured such that, as a result of said second information indicating that that the second network peer responded to the second communication message by transmitting a responsive communication message in said second control plane format, the processing circuitry determines that the second network peer node is utilizing the second version of the PMIPv6 control plane.
22. The first network peer node of claim 15, wherein
the obtained second information indicates that the second network peer responded to the first communication message by transmitting a responsive communication message in said first control plane format, and
the processing circuitry is configured such that, as a result of said first information indicating that that the second network peer responded to the first communication message by transmitting a responsive communication message in said first control plane format, the processing circuitry determines that the second network peer node is utilizing one of the first version of the PMIPv6 control plane and the second version of the PMIPv6 control plane.
23. The first network peer node of claim 15, wherein
the processing circuitry is further configured to employ the transmitting circuitry to send, to the second network peer node, a second communication message in a second control plane format, said second control plane format being a control plane format according the RFC Control Plane Format, wherein
the processing circuitry is further configured to employ the transmitting circuitry to send the second communication message prior to the processing circuitry obtaining said first information.
24. The first network peer node of claim 23, wherein if only one communication response is received from the second network peer node, the processing circuitry is further configured to determine the PIMPv6 control plane value to be the control plane format of the received communication response.
25. The first network peer node of claim 23, wherein if a plurality of communication responses are received from the second network peer node, the processing circuitry is further configured to determine the PIMPv6 control plane value to be a default control plane format.
26. The first network peer node of claim 25, wherein the default control plane format is control plane A.
27. The first network peer node of claim 23, wherein if no responses from the second network peer node are received within a predetermined period of time, the communication response is an internal notification that indicates communication with the second network peer node is not possible, and the processing circuitry is further configured to determine the PIMPv6 control plane is a null value.
28. The first network peer node of claim 18, wherein the first control plane format is control plane A and the second control plane format is control plane C.
29. The first network peer node of claim 23, wherein the first control plane format is control plane A and the second control plane format is control plane C.
30. The method of claim 9, wherein the first control plane format is control plane A and the second control plane format is control plane C.
31. The method of claim 1, wherein the draft of RFC 5844 is draft-ietf-netlmm-pmip6-ipv4-support-NN, wherein NN is less than 18.
US13508544 2011-08-17 2012-04-26 PMIP protocol enhancement Active 2035-02-06 US9749838B2 (en)
US201161524552 true 2011-08-17 2011-08-17
PCT/EP2012/057626 A-371-Of-International WO2013023798A1 (en) 2011-08-17 2012-04-26 Pmip protocol enhancement
US20130044682A1 true US20130044682A1 (en) 2013-02-21
US9749838B2 true US9749838B2 (en) 2017-08-29
ID=47712601
US13508544 Active 2035-02-06 US9749838B2 (en) 2011-08-17 2012-04-26 PMIP protocol enhancement
US15651096 Pending US20170318451A1 (en) 2011-08-17 2017-07-17 Pmip protocol enhancement
US (2) US9749838B2 (en)
WO2007023966A1 (en) 2005-08-25 2007-03-01 National Institute Of Information And Communications Technology, Incorporated Administrative Agency Communication apparatus, communication method, communication protocol processing method, communication terminal apparatus, communication method thereof, communication system and communication method thereof
EP2247079A1 (en) 2009-04-29 2010-11-03 Alcatel Lucent Method of private addressing in a proxy mobile IP networks
CN101977246A (en) 2010-09-07 2011-02-16 南京中兴软件有限责任公司;中兴通讯股份有限公司 Method and system for supporting PMIPv6 (Proxy Mobile IPv6) mobility
US20120179803A1 (en) * 2009-07-03 2012-07-12 Telemaco Melia Enhancing network-based ip mobility management protocol to provide multihoming support
JP2012227664A (en) 2011-04-18 2012-11-15 Ntt Docomo Inc Mobile communication method, mobile management node, and packet switch
CN101897217A (en) 2007-11-12 2010-11-24 华为技术有限公司 Internet protocol version 4 support for proxy mobile internet protocol version 6 route optimization protocol
CN101925055A (en) 2009-04-29 2010-12-22 阿尔卡特朗讯公司 Method of private addressing in a proxy mobile IP networks
3GPP TS 29.275, Release 9, Technical Specification Group Core and terminals; Proxy mobile IPv6(PMIPv6) based mobility and tunnelling, Mar. 2010, pp. 1-75. *
Communication pursuant to Article 94(3) EPC issued for European patent application No. 12 718 180.8 dated Nov. 28, 2016, 4 pages.
Devarapalli V et al. "Heartbeat Mechanism for Proxy Mobile IPv6; RFC 5847", Internet Engineering Task Force (IETF), Jun. 2010 (Jun. 2010), pp. 1-11, XP015070837, ISSN: 2070-1721 [retrieved on Jun. 11, 2010] the whole document.
First Office Action dated Mar. 3, 2017 in corresponding Chinese Application No. 201280051162.7, 12 pages.
International Search Report and Written Opinion issued in corresponding International Patent Application No. PCT/EP2012/057626, issued by the European Patent Office with mailing date Aug. 6, 2012.
Internet Engineering Task Force, IETF; Standard; 11 June 2010 (2010-06-11), V. DEVARAPALLI, ED. WICHORUS R. KOODLI, ED. CISCO SYSTEMS H. LIM N. KANT STOKE S. KRISHNAN J. LAGANIER QUALCOMM INC.: "Heartbeat Mechanism for Proxy Mobile IPv6; rfc5847.txt", XP015070837, Database accession no. 5847
Internet Engineering Task Force, IETF; Standard; 24 May 2010 (2010-05-24), R. WAKIKAWA TOYOTA ITC S. GUNDAVELLI CISCO: "IPv4 Support for Proxy Mobile IPv6; rfc5844.txt", XP015070812, Database accession no. 5844
Office Action issued on Feb. 2, 2016 in corresponding Japanese Patent Application No. 2014-525354, 5 pages.
Office Action issued on Jul. 11, 2016 in corresponding Russian Patent Application No. 2016122064/20, 3 pages.
Search Report dated Feb. 23, 2017 in corresponding Chinese Application No, 201280051152.7, 2 pages.
Wakikawa R et al.: "IPv4 Support for Proxy Mobile IPv6; RFC 5844", Internet Engineering Task Force (IETF), May 20 (May 2010), XP015070812, ISSN: 2070-1721 [retrieved on May 24, 2010] cited in the application, section 4, figure 10.
Wakikawa R et al.: "IPv4 Support for Proxy Mobile IPv6; RFC 5844", Internet Engineering Task Force (IETF), May 20 (May 2010), XP015070812, ISSN: 2070-1721. *
US20130044682A1 (en) 2013-02-21 application
US20170318451A1 (en) 2017-11-02 application
US20090176489A1 (en) 2009-07-09 Apparatus and Methods to Facilitate Seamless Handoffs between Wireless Communication Networks
US20110299463A1 (en) 2011-12-08 Optimized home link detection
US20080089251A1 (en) 2008-04-17 Packet Data Transmission
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:QIANG, ZU;YANG, YONG;SIGNING DATES FROM 20120510 TO 20120516;REEL/FRAME:028276/0808