[go: up one dir, main page]

WO2006067568A1 - Protocole de transport à emplacements multiples utilisé dans un arrangement à processeurs multiples - Google Patents

Protocole de transport à emplacements multiples utilisé dans un arrangement à processeurs multiples Download PDF

Info

Publication number
WO2006067568A1
WO2006067568A1 PCT/IB2005/003680 IB2005003680W WO2006067568A1 WO 2006067568 A1 WO2006067568 A1 WO 2006067568A1 IB 2005003680 W IB2005003680 W IB 2005003680W WO 2006067568 A1 WO2006067568 A1 WO 2006067568A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
communication unit
address
data processing
external
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.)
Ceased
Application number
PCT/IB2005/003680
Other languages
English (en)
Inventor
Hui Huang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Inc
Original Assignee
Nokia Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US11/206,015 external-priority patent/US20060133343A1/en
Application filed by Nokia Inc filed Critical Nokia Inc
Publication of WO2006067568A1 publication Critical patent/WO2006067568A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/2521Translation architectures other than single NAT servers
    • H04L61/2525Translation at a client
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • H04L61/2585NAT traversal through application level gateway [ALG]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Definitions

  • the invention relates to a processing arrangement (to be used, for example, in a communication device) and a method, wherein a communication unit and at least one data processing unit are separately provided and a multi-homing packet transport protocol is used.
  • a multi-homing packet transport protocol is a transport protocol which supports multi-homed nodes , i . e . , nodes which each can be reached under several addresses .
  • An example for such a transport protocol is SCTP (Stream Control Transport Protocol) .
  • Transport layer multi-homing and mobility have been proposed in new Internet transport protocols, such as the SCTP mentioned above .
  • the feature of multi-homing can be utilized in multi-homed mobile devices (such as a mobile device having simultaneous 2G (second generation) , 3G (third generation) , WLAN (Wideband Local Area) and Bluetooth accesses) , for example) , and provides the benefit for redundancy, load balancing and mobility.
  • SCTP has been received much attention due to its attractive features of multi-homing and multi-streaming. It has been proposed to be a transport protocol for multimedia transmission in addition to signalling transmission.
  • multi-processor architecture has been used for mobile phones .
  • one processor handles the communication processing and is called COM engine, and the other processor called APE (Application Processor Environment) engine handles application processing for various applications that may be running on the terminal .
  • APE Application Processor Environment
  • two Operation Systems are built on top of the two processors, respectively.
  • a multi-homed SCTP endpoint can be represented as a list of SCTP transport addresses on the machine that share a single SCTP port . Then, the SCTP endpoint can be denoted by a list of addresses and one port number :
  • SCTP endpoint [address 1, address 2, address n : port number]
  • SCTP can provide a kind of mobility at the transport layer by adding/deleting an address .
  • SCTP has a new system call bindx to bind multiple local addresses to its port, and send its local address list to the remote peer during association establishment .
  • SCTP is an end-to-end transport protocol, and a multi- homed SCTP endpoint can establish multiple paths to the remote SCTP peer . For this reason, SCTP must provide its address information to its peer in the so-called INIT/INIT-ACK chunks during the association setup phase .
  • a processing arrangement comprising at least one data processing unit, and a communication unit connected to the data processing unit, wherein the at least one data processing unit is configured to perform data processing and the communication unit is configured to provide a connection to the external, a packet transport control is used for the connection to the external, in which a plurality of addresses may be assigned to the communication unit, and the communication unit comprises an address translating means for translating packet addresses of packets sent from the external to the data processing unit and/or packets sent from the data processing units to the external .
  • the above object is solved by a method for performing communication of a processing arrangement comprising at least one data processing unit, and a communication unit connected to the data processing unit and configured to provide a connection to an external node, wherein a packet transport control is used for the connection between the communication unit and the external node, in which packet transport protocol a plurality of addresses may be assigned to the communication unit, the method comprising the step of translating packet addresses of packets sent from the external node to the data processing unit and/or packets sent from the data processing units to the external node .
  • a communication unit for providing a connection to the external wherein a packet transport control is used for the connection to the external, in which a plurality of addresses may be assigned to the communication unit, and the communication unit comprises an address translating means for . translating packet addresses of packets sent from the external to at least one data processing unit and/or packets sent from at least one data processing unit to the external .
  • a translation of addresses is performed, namely between the plurality of external addresses assigned to the processing arrangement (which is used, for example, in a communication device) and the internal address of the data processing unit, e . g . , the APE processor .
  • an external host can receive the packets from one of the addresses of the processing arrangement, and send packets to one of the addresses of the processing arrangement, but for the data processing unit, all sent packets comprises only its own (internal ) address as the source address , and all received packets comprises only its own address as destination address .
  • the data processing unit can use the features of the multi-home packet transport protocol
  • transport layer multi-homing and mobility can easily be provided for dual-processor communication devices .
  • the address translating means may comprise a packet receiving means for receiving a packet transmitted via a transport layer, wherein the packet receiving means detects whether the received packet is an incoming or an outgoing packet .
  • the address translating means may replace a source address of a packet received from the data processing unit by a selected one of the plurality of addresses of the communication unit in a packet sent from the data processing unit to the external .
  • the address translating means may comprise a source address selecting means for selecting a source address of the plurality of addresses of the communication unit .
  • the address translating means may comprise means for replacing a destination address of a packet received from the external by an address of the data processing unit .
  • the address translating means may comprise packet type detecting means for detecting the type of a packet and for forwarding the packet to an application part of the communication unit depending on the type of the packet . [0024] .
  • the packet type detecting means may detect the type of a packet by detecting a port number of the packet .
  • the address translating unit may detect whether an outgoing packet comprises a network transport protocol initialization message, and, if it comprises an initialization message, it may include the addresses of the communication unit into the initialization message .
  • the communication unit may change at least one of its addresses, and the translating unit may perform signalling exchange with the external regarding the address change .
  • the translating unit may include the at least one changed address into a packet transport protocol message .
  • Transport protocol may be, for example, Stream Control Transport Protocol (SCTP) , Datagram Congestion Control Protocol (DCCP) or Transport Control Protocol - Multi-Homing (TCP-MH) .
  • SCTP Stream Control Transport Protocol
  • DCCP Datagram Congestion Control Protocol
  • TCP-MH Transport Control Protocol - Multi-Homing
  • the processing arrangement may comprise a first and a second processor, wherein the first processor comprises the data processing unit and the second processor comprises the communication unit .
  • the processing arrangement may be a chipset for example, which is designed for use in a communication device or other suitable devices .
  • Fig . 1 shows an external host and a mobile device according to an embodiment of the present invention
  • Fig . 2 shows function modules in an SCTP layer of a COM engine of the mobile device according to the embodiment of the present invention .
  • SCTP Stream Control Transport Protocol
  • An SCTP protocol data unit consists of a common header including source and destination addresses, verification tag and checksum, and of one or more so-called chunks .
  • a chunk is a unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content .
  • a simplified NAT Network Address Translator
  • SCTP-ALG Application Layer Gateway
  • COM Communication Module
  • NAT would do IP address translation for the outgoing/incoming packets .
  • APE Application Processor Environment
  • its source address is the IP address of the APE engine .
  • the source address of SCTP packet will be translated to one address of the COM engine such that it looks like packets are sent out from COM directly. In this way, the mobile host can inform the external host the addresses on the mobile device .
  • mobility can be supported by sending special signaling of add/delete IP addresses from SCTP-ALG to the remote host, as will be described later .
  • FIG. 1 shows a detailed example of the structure of a mobile device A comprising NAT and SCTP- ALG according to an embodiment of the present invention in connection with an external host B .
  • the mobile device A comprises an APE engine 1 and a COM engine 2.
  • the APE engine 1 comprises an application block 10 , an SCTP block 11 and an IP/links block 12.
  • the COM engine 2 comprises an SCTP block 21 , an IP/links block 22 and additionally a NAT/SCTP-ALG block 23 including the NAT and SCTP-ALG function modules according to the present embodiment, which will be described in the following in more detail .
  • the NAT/SCTP- ALG block is arrangement within the IP/links block 22.
  • the APE and COM engine are connected via a ppp (point-to- point protocol) link. Basically, APE handles application processing and COM handles communication to the external hosts (i . e . , the communication to the external) .
  • NAT and SCTP-ALG function modules are located in the COM Linux OS
  • SCTP packets are transmitted between the APE engine 1 and the external host (remote peer) B .
  • its source address is the IP address of the APE engine .
  • the source address of SCTP packet will be translated to one address of COM such that it looks like packets are sent out from COM directly.
  • an external host will send its response packets to COM.
  • the NAT SCTP-ALG function module 23 (in detail, the NAT function module thereof) will translate the destination IP address to the IP address of APE .
  • the NAT and SCTP-ALG function module 23 adds the address information of the COM engine into an INIT chunk. Namely, as mentioned above, upon establishing an SCTP association, the APE engine sends an INIT chunk to the external host . Thus , when the COM engine 2 receives a SCTP INIT chunk from the APE engine 1, it will remove the APE ' s address and add the COM' s address in the INIT chunk and then forward it to the remote peer .
  • the SCTP endpoint in the APE engine is able to be aware of all IP addresses of the external SCTP endpoint B .
  • the external SCTP endpoint informs the APE engine of all IP addresses in SCTP INIT_ACK chunk.
  • the chunks inside SCTP packet from external SCTP endpoint are not changed by the COM engine .
  • the proposed scheme will not affect the Heartbeat function of SCTP.
  • the Heartbeat function defined for SCTP serves to check the reachability of a particular destination transport address defined in the present association. For this, a so called Heartbeat Request (HEARTBEAT) is sent, which is answered by a Heartbeat Acknowledgment (HEARTBEAT ACK) .
  • HEARTBEAT Heartbeat Request
  • HEARTBEAT ACK Heartbeat Acknowledgment
  • SCTP-ALG should be aware of changes of the interfaces of COM.
  • SCTP-ALG sends Add/Delete IP signaling (ASCONF/ASCONF-ACK) to the remote peer and notifies the addresses changes . That is, the SCTP-ALG sends an ASCONF (Address Configuration) chunk including a parameter "Add IP address" or "Delete IP address” to the remote peer, which responds with an ASCONF-ACK (Address configuration acknowledgement) chunk.
  • ASCONF Address Configuration
  • COM wants to send an ASCONF chunk or an ASCONF-ACK chunk to the corresponding association
  • the COM engine keeps a record of all active associations , but it may not maintain all of the information of each association, only the address information and the timer of Add-ip .
  • COM since COM is inside of a SCTP client of mobile terminal, so normally, it will not have many associations at the same time .
  • Source address selection of SCTP packet is performed in NAT according to the destination address of the remote SCTP peer .
  • the SCTP protocol stack is at the Linux kernel . Therefore, the NAT and SCTP-ALG function modules are implemented in the kernel and then co-work with SCTP protocol stack. In this way, the NAT and SCTP-ALG is completely transparent to user layer applications . That is , the user layer applications are not aware of the existence of the NAT and SCTP-ALG.
  • Fig. 2 shows, function modules in the Linux kernel, i . e . , in the SCTP layer, which are part of the NAT and SCTP-ALG module 23 shown in Fig. 1.
  • the ' SCTP layer is located in the Linux kernel between the user space applications and the IP layer
  • the SCTP capturer 230 receives an SCTP packet from IP layer, which may be an SCTP packet sent by the APE engine (outgoing packet) or an SCTP packet sent by a remote host (incoming packet) .
  • IP layer may be an SCTP packet sent by the APE engine (outgoing packet) or an SCTP packet sent by a remote host (incoming packet) .
  • the SCTP capturer 230 judges whether the packet is an outgoing SCTP packet to external network or an incoming SCTP packet from external network. For example, this is effected by evaluating the destination and/or source addresses of the packet .
  • the SCTP-ALG module 231 checks whether it is an INIT chunk or not . If it is an INIT chunk, the SCTP-ALG module 231 will add the external address information of the COM engine (i . e . , the IP addresses under which the COM engine is reachable) to the address list in INIT chunk. It is noted that this addition leads to a change of the payload of the SCTP packet . Hence, the checksum of the SCTP packet should be recalculated and rewritten in the corresponding header field of the SCTP packet .
  • a further example for an outgoing packet is an ASCONF chunk or an ASCONF-ACK chunk including Add/delete IP signaling, as described above, which is sent to the remote host for mobility support .
  • This action can be triggered from IP layer or Link layer, when the mobile device performs a handover to a new access network.
  • the SCTP-ALG module 231 sends an ASCONF chunk to the remote host with changed addresses of the COM engine .
  • Source address selection module 234 (2) Source address selection module 234 :
  • the SCTP-ALG module 232 forwards the packets to a source address selection module 234.
  • the source address selection module 234 of the NAT selects a source address for the outgoing SCTP packet based on the destination address of the packet or the bandwidth of the access link.
  • the outgoing packet is then forwarded to an IP address translator 233 described later .
  • the selection of the source address can be performed in the following way, for example .
  • the source address selection is based on the destination address . This function is effected by selecting a routing entry from the routing table which has a route to the destination. The source address or the interface address is read from the routing entry.
  • the SCTP capturer 230 receives an incoming SCTP packet, this packet is forwarded to a port number detector 231.
  • the port number detector 231 is used to j udge whether the SCTP packet should be terminated ' at the COM engine or forwarded to the APE engine .
  • server applications are running on the COM engine and client applications are running on the APE engine .
  • client applications are running on the APE engine .
  • server applications running on the COM engine
  • the server applications use well-known port numbers below 1024. Therefore, if the destination port number is between 0-1024 , then the SCTP packet will be passed to the application layer (as indicated by the arrow in Fig . 2 directed upwards ) , otherwise the SCTP packet goes to an IP address translator 233 described in the following .
  • the incoming SCTP packet is forwarded to the applications or to an IP address translator 233 described in the following .
  • IP address translator 233 ( 5) IP address translator 233 :
  • the translator 233 performs the IP address translation for both outgoing and incoming packets .
  • the source address is translated to one of the IP addresses of the external interface (i . e . , one of the IP addresses of the COM engine) .
  • the destination address is translated to the address of APE engine .
  • the packet is returned to the IP layer, where it is forwarded to the remote peer or to the APE engine 1, depending on the destination address .
  • the address translation performed by the corresponding function modules of the COM engine is transparent to upper layer application. It is no more communication between APE and COM engines necessary than it is in the prior art APE and Com engines .
  • SCTP-ALG may utilize some function of the SCTP protocol stack in suitable manner .
  • the invention is not limited to the use of SCTP .
  • Any transport layer protocol which has multi-homing support e . g . SCTP, DCCP, TCP-MH
  • SCTP transport layer protocol which has multi-homing support
  • DCCP DCCP
  • TCP-MH transport layer protocol which has multi-homing support
  • the dual-processor mobile phone described in the embodiment above is only an example for a communication device . That is , the invention can be applied to any communication device in which the communication function and other functions are separated between different entities .
  • the communication device is not limited to a mobile communication device .
  • the invention can be applied to other devices in which a , processing arrangement comprising at least one data processing unit and a communication unit is used.
  • a processing arrangement may be a chipset or may be a part of a chipset to be used for a communication device or the like .
  • the data processing functions may also be performed in more than one entity (e . g. , there may be two or more APE processors ) .
  • each APE engine data processing unit
  • the COM engine has to correspondingly translate the addresses for the plurality of APE engines .
  • a complete NAT-PT (Network address translation and port number translation) function should be provided at the COM engine, the COM engine needs to record the status of each SCTP association on multiple APEs and then assign different port numbers to the associations .
  • Linux was described as an example for an operating system for the APE and COM engines .
  • any suitable operating system can be used instead.
  • the function modules shown in Fig . 2 can be realized by software, but can also be suitable hardware .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un arrangement de traitement (utilisable dans un dispositif de communication, par exemple), qui comprend au moins une unité de traitement de données (1) et une unité de communication (2) connectée à l'unité de traitement de données (1). L'unité de traitement de données (1) est configurée pour effectuer un traitement de données, et l'unité de communication (2) est configurée pour assurer un raccordement à un hôte extérieur. De plus, une commande de transport par paquets est utilisée pour raccordement à l'hôte extérieur dans lequel une pluralité d'adresses peuvent être envoyées à l'unité de communication (2). L'unité de communication comprend un moyen de traduction d'adresses (23) servant à traduire des adresses de paquets envoyées de l'hôte extérieur à l'unité de traitement de données et/ou de paquets envoyées des unités de traitement de données à l'hôte extérieur. L'invention concerne en outre un procédé de communication correspondant.
PCT/IB2005/003680 2004-12-22 2005-12-06 Protocole de transport à emplacements multiples utilisé dans un arrangement à processeurs multiples Ceased WO2006067568A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP04030444 2004-12-22
EP04030444.6 2004-12-22
US11/206,015 2005-08-18
US11/206,015 US20060133343A1 (en) 2004-12-22 2005-08-18 Multi homing transport protocol on a multi-processor arrangement

Publications (1)

Publication Number Publication Date
WO2006067568A1 true WO2006067568A1 (fr) 2006-06-29

Family

ID=35788658

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2005/003680 Ceased WO2006067568A1 (fr) 2004-12-22 2005-12-06 Protocole de transport à emplacements multiples utilisé dans un arrangement à processeurs multiples

Country Status (1)

Country Link
WO (1) WO2006067568A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020075900A1 (en) * 2000-12-18 2002-06-20 Klaus Turina Signaling transport protocol extensions for load balancing and server pool support
US20040028009A1 (en) * 2002-08-06 2004-02-12 Motorola, Inc. Method and apparatus for effecting a seamless handoff between IP connections
US20040197079A1 (en) * 2001-11-05 2004-10-07 Nokia Corporation Method and a system for stateless load sharing for a server cluster in an IP-based telecommunications network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020075900A1 (en) * 2000-12-18 2002-06-20 Klaus Turina Signaling transport protocol extensions for load balancing and server pool support
US20040197079A1 (en) * 2001-11-05 2004-10-07 Nokia Corporation Method and a system for stateless load sharing for a server cluster in an IP-based telecommunications network
US20040028009A1 (en) * 2002-08-06 2004-02-12 Motorola, Inc. Method and apparatus for effecting a seamless handoff between IP connections

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WEI XING ET AL: "M-SCTP: Design and Prototypical Implementation of an End-To-End Mobility Concept", -, 1 October 2002 (2002-10-01), XP002350786 *

Similar Documents

Publication Publication Date Title
US20060133343A1 (en) Multi homing transport protocol on a multi-processor arrangement
US11265238B2 (en) Bypassing routing stacks using mobile internet protocol
KR101442309B1 (ko) 다수의 아답터들을 통해서 다수의 가상 ip 어드레스를 동시에 지원하는 호스트내 페일오버
EP1349322B1 (fr) Procedeé, dispositif et medium pour migration entre les technologies de liens
EP2465244B1 (fr) Procédé et dispositif pour des environnement multiples de NAT64
US5796727A (en) Wide-area wireless lan access
US6940835B2 (en) Application-level mobility support in communications network
Bhagwat et al. A Mobile Networking System Based on Internet Protocol (IP).
EP2854360B1 (fr) Procédé pour relier un premier hôte et un second hôte dans au moins un réseau de communication à travers un module de relais, module de relais correspondant
US8180902B1 (en) Establishing network connections between transparent network devices
US20130194963A1 (en) Method and apparatus for end-host based mobility, multi-homing and multipath protocols
CN102148767A (zh) 一种基于nat的数据路由方法及其装置
JP2008295043A (ja) ネットワークトラフィックのインテリジェントロードバランシング及びフェイルオーバー
JP2003163689A (ja) ネットワーク連携情報処理システムおよびその複数負荷分散機間のアクセス移動方法
WO2007033363A2 (fr) Systeme et procede permettant d'obtenir une connectivite par paquets entre des reseaux heterogenes
EP3395049B1 (fr) Routeur et procede pour connecter un reseau ipv4 et un reseau ipv6
US20070002822A1 (en) Multi homing transport protocol on a multi-processor arrangement
JP2003258859A (ja) 通信システム、通信方法、転送装置及びネットワーク管理装置
JP3979255B2 (ja) 外部接続ルータの切替方法、切替元の外部接続ルータ及び切換先の外部接続ルータ
WO2006067568A1 (fr) Protocole de transport à emplacements multiples utilisé dans un arrangement à processeurs multiples
JP2006333080A (ja) 携帯通信端末および通信経路選択方法と通信経路選択プログラム
Kimura et al. Tips: wrapping the sockets api for seamless ip mobility
JP3889981B2 (ja) 移動ノード、移動通信システム及び通信制御プログラム
CN100512172C (zh) 一种柔性ip网络技术体系中实现自适应扩展域管理实体机制的方法
Bhagwat A framework for integrating Mobile Hosts within the Internet

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05812741

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 5812741

Country of ref document: EP