BRPI0617273A2 - base station methods and equipment for establishing connections - Google Patents

Abstract

BASE STATION METHODS AND EQUIPMENT FOR ESTABLISHING CONNECTIONS. Methods and equipment for establishing communication links, used to support communication sessions with one or more terminal nodes, such as, for example, mobile devices, are described. Several aspects refer to a mobile node that controls the establishment of initial links with a first access node and the esoaoelimento of new links from a first access node with a second access node during a handoff operation using messages and a highly effective signal.

Description

"METHODS AND BASIC STATION EQUIPMENT FOR ESTABLISHING CONNECTIONS".

Field of the Invention

This invention relates to a communication system and more specifically to methods and equipment for establishing connections in wireless communication networks such as cellulars.

Description of the Prior Art

Communication systems often include a plurality of network nodes that are coupled to access nodes through which end nodes, such as mobile devices, are coupled to the network. Nodes can be arranged in a hierarchy. Authentication and Access Authorization (AAA) servers are nodes that are normally placed high in the network hierarchy. They typically provide the information used for security and access control purposes. Access nodes often have a secure connection with an AAA server where such servers are used. The secure link can be through one or more nodes in the hierarchy.

Operators typically manage access sessions on IP networks using the RADIUS protocol, associated AAA RADIUS servers. In the future, AAA systems may be based on new protocols such as DIAMETER. On a system using an AAA RADIUS server, when the user attempts to gain access to a carrier network for the duration of an access session, the local Access Router typically issues one or more RADIUS Access Requests to an Authentication Server to authenticate this user with based on your identity, such as a Network Access Identifier (NAI). The AA database typically has the identities of users authorized to access your system stored along with the service features they can call. When the user is successfully authenticated, their access port on the access device is set to a commensurate policy state with the User Service Authorization. Service authorization is typically delivered through RADIUS to the Access Router by the Authorization Server. While authorized, service usage during an access session is recorded by the Access Router, and sent as a count record to an Accounting Server using Accounting Request messages. in the RADIUS protocol. The Accounting Server may be part of the AAA server or may be a standalone server using the same protocol as the authorization server. If the user is logged in; multiple Access Routers during a single session, then multiple sessions need to be aggregated with Accounting Servers.

AAA systems are typically used with IPMobile to manage IP address allocations (HoAs), to dynamically allocate HAs, to distribute MN profiles to the Acesso Access Router, and also to distribute security keys to authenticate MIP messages and to secure the air link. The Mobile Node, an end node that is capable of changing its coupling point to the network, typically sends a MIP message to gain access to the system, triggering an AAA request to authenticate and authorize the Mobile Node. The MN AAA profile and security state are then passed from the AAA system to the Access Router to control the services consumed by the MN.

MNs can change their mating point, such as as they move from cell to cell. This involves changing the MNs coupling point from a first access node, such as a first router, to a second access node, such as a second router. This process is commonly known as handoff. As part of a handoff, CoA / CCoA MNs need to be updated and then transferred to HA using MIP signaling, so that packets are redirected to MN via a new Access Router. As part of the handoff process, it is necessary to transfer at least some of the state information from the first access router, which corresponds to the MN involved in the handoff, to the new access router, so that the MN service is not broken. This process is known as State Transfer. The state transfer may include, for example, the transfer of state information from the AAA profile that was previously delivered through RADIUSao AR, at which the MN access session began. This may also include, for example, air link security vector transfer, MN-NAI, MN IP Address, MN-EUI-64, Remaining MIP Record Lifetime, MN Multicast Group Member, Admission Control Status , resource reservation status, different service state, SIP session state, compressor state, MN programming history, and / or many other potential items from MN-specific AR state information.

In at least one known system, state information transfer during a handoff is effected by the new access node to which a mobile node is connecting by sending a state transfer message through the communication network to the old access node to which the mobile node was connected. . In response, the old access node issues status information to the new access node. Alternatively, a core node is used to store the state associated with a given mobile node. When the mobile node attempts to move to another target access node, the target access node may recover the state associated with the core node node.

Mobile IP (versions 4 and 6), also known as MIPv4 [MIPv4] and ΜΙΡνβ [ΜΙΡνβ], allows a mobile node (MN) to register its temporary location indicated by a temporary address (CoA) with its Originating Agent (HA) . HA then maintains a mapping (also called a link) between the MN permanent address, also called Originating Address (HoA), and the registered CoA so that packets to this MN can be redirected to their current location using IP tunneling techniques. . The CoA used by an MN may be an address that belongs to a Foreign Agent (FA) on an Access Router when MIPv4 is used or it may be a temporarily allocated address to MN itself, from the Access Router prefix, and in this case This is called a co-located temporary address (CCoA).

This latter model also applies to MIPv4, whereas it is the only mode of operation in ΜΙΡνβ. Note that, for the purposes of this document, the terms CCoA and CoA, as well as Registration and Linkage Update (BU) are interchangeable as they are corresponding terms for MIPv4 and ΜΙΡνβ.

The shortest possible MIPv4 Registration Request message includes at least the following headers and fields.

- IP header (at least 160 bit length)

- UDP header (at least 64-bit length)

The UDP header is followed by the Mobile IP fields shown below: (length of at least 192 bits) <table> table see original document page 6 </column> </row> <table>

Type 1 (Registration Request)

S Simultaneous links. If the xS 'forest bit is set, the mobile node prompts the source agent to maintain its previous mobility bindings.

B Datagrams of diffusion. If the 'B' forest is set, the mobile node requests the source agent to tunnel to it any broadcasting datagrams it receives on the source network.

D Decapsulation by the mobile node. If the xD bit is set, the mobile node itself will decapsulate the datagrams that are sent to the temporary address. That is, the mobile node uses a co-located temporary address.

M Minimum encapsulation. If the forest bit is set, the mobile node prompts its source agent to use minimal tunneling [34] for tunneled schemes for the mobile node. ; G GRE encapsulation. If ο bit xG 'is set, the

Mobile node requests that its originating agent use GRE encapsulation [16] for tunneled datagrams to the mobile node.

r Sent as zero; ignored at reception.

T Reverse tunneling requested.

χ Sent as zero; ignored at reception.

Lifetime

The number of seconds left before the record is considered expired. A value of zero indicates an unregister request. An Oxffffindic value indicates infinity.

Origin Address

The IP address of the mobile node. Source Agent

The IP address of the source agent of the mobile node.

Temporary Address

The IP address for the end of the tunnel.

Identification

A 64-bit number, built by the mobile node, used to compare Log Requests with Log Replies, and to protect against log message replay attacks.

Extensions (length at least 176 bits)

The fixed part of the Registration Request is followed by one or more of the Extensions.

An extension to enable authorization MUST be included in all Registration Requests. <table> table see original document page 8 </column> </row> <table>

Type

32

Length

4 plus the number of bytes in the Authenticator.

SPI

Safety Parameter index (4 bytes). Opaque identifier.

Authenticator

The default authentication algorithm uses HMAC-MD5 to compute a 128bit "message compilation" of the log message.

Authenticator Extension

<table> table see original document page 8 </column> </row> <table>

Type

32

Length

4 plus the number of bytes in the Authenticator.

SPI

Safety Parameter index (4 bytes). Opaque identifier.

AuthenticatorThe default authentication algorithm uses HMAC-MD5 to compute a 128bit "message compilation" of the log message.

The smallest possible MIPv4 Registration Request message shown above is 592 bits long, which may result in inefficient use of resources when it has to be transmitted over a wireless link for registration and handoff purposes. Note that in practice typical MIPv4 Request for Registration messages are significantly larger than the calculated minimum value, but the minimum value is used for purposes of example.

The shortest possible Record Response message according to MIPv4 includes at least the following headers and fields.

- IP header (at least 160 bits in length)

- UDP header (at least 64 bits long)

The UDP header is followed by the Mobile IP fields shown below: (at least 160 bits in length)

<table> table see original document page 9 </column> </row> <table> Type 3 (Registration Response)

Code A value that indicates the result of the Registration Request.

Lifetime

If the Code field indicates that the record is accepted, the Lifetime field is fixed at the number of seconds remaining before the record is considered expired. A zero value indicates that the mobile node has been unregistered. An Oxffffindic value indicates infinity.

Origin Address

The IP address of the mobile node.

Originating Agent

The IP address of the source agent of the mobile node.

Identification

A 64-bit number used to compare Log Requests with Log Replies and to protect against log message playback attacks.

Extensions (at least 176 bits in length)

The fixed part of the Registration Response is followed by one or more of the Extensions.

An extension to enable authorization MUST be included in all Registration Responses.

Authenticator Extension

<table> table see original document page 10 </column> </row> <table> Type

32

Length

4 plus the number of bytes in the Authenticator.

SPI

Safety Parameter index (4 bytes). Opaque identifier.

The default authentication algorithm uses HMAC-

MD5 to compute a 128-bit "message compilation" of the log message.

The smallest possible MIPv4 Compliant Registration Response message shown above is 560 bits long, which can result in inefficient use of resources when it has to be transmitted wirelessly for registration and handoff purposes. Note that in practice typical MIPv4 Record Response messages are significantly larger than the minimum calculated value, but the calculated minimum value is used for example purposes.

It should also be noted that, as is well known to those skilled in the art, the smallest Update Binding possible according to Mobile IPv6 (MIPv6) (equivalent to a MIPv4 Registration Request) is larger than the smallest possible Registration Request message according to MIPv4. . Finally, note that, as is well known to those skilled in the art, the smallest possible IPv6Mobile (MIPv6) Binding Confirmation (equivalent to a MIPv4 Registration Response) is larger than the smallest possible MIPv4 Registration Response message.

In view of the above discussion, it should be understood that there is a need for new and more efficient methods for implementing network links with access nodes in the case of an initial registration of a mobile node with a network, a handoff for a new access node, or in other cases when a mobile node enters a new cell.

Summary of the Invention

The present invention relates to methods and equipment for establishing connections between wireless terminals and access nodes.

Various methods and equipment of the invention may be used to establish common communication links or more mobile nodes. Established links can be used to support communication sessions with one end node, such as mobile devices.

Several new features refer to methods on mobile nodes to control the establishment of initial links to a first access node. Other features refer to establishing a new link as part of a mobile node handoff from a first access node to a second access node during a handoff operation using highly efficient messages and signal.

Highly efficient messages, often much shorter than IPv4 or mobile IPv6 messages that can be used to perform similar tasks are generated, used and stored according to various embodiments of the invention.

While some features relate to methods and wireless terminal equipment, as well as to new messages of the invention stored in a wireless terminal, other features are directed to new access node methods and equipment.

The invention also relates to data storage devices, such as memory devices, which store one or more of the new messages of the present invention.

Additional features and benefits of the present invention are discussed in the following detailed description.

Brief Description of the Figures

Figure 1 shows a network diagram of an exemplary communication system implemented in accordance with the present invention.

Figure 2 shows an exemplary end node implemented in accordance with the present invention.

Figure 3 shows an exemplary access node implemented in accordance with the present invention.

Figure 4 shows an exemplary Server Node implemented in accordance with the present invention.

Figure 5 shows an example Source Agent node implemented in accordance with the present invention.

Figure 6 shows an exemplary reduced IP log message implemented according to this invention.

Figure 7 shows an exemplary reduced size IP record response message implemented according to this invention.

Figure 8 shows an exemplary signaling performed in accordance with the present invention when a terminal node transits from one access node to another access node.

Detailed Description of the Invention

The methods and equipment of the present invention for establishing link and network connections with access nodes used to support common communication sessions or more end nodes, such as mobile devices, may be used with a wide range of communication systems. For example, the invention may be used with systems that support mobile communication devices such as portable computers equipped with modems, PDAs, and a wide variety of other devices that support wireless interfaces in the interest of device mobility. .

Figure 1 shows an exemplary communication system implemented in accordance with the present invention, such as a cellular communication network, comprising a plurality of nodes interconnected by communication links. The nodes in the exemplary communication system 100 exchange information using signals, such as messages, based on communication protocols, such as the Internet Protocol (IP). System 100 communication links can be implemented, for example, using wires, fiber optic cables, and / or wireless communication techniques. Exemplary communication system 100 includes a plurality of end nodes 144, 146, 144 ', 146', 144 ", 146", which access the communication system through a plurality of access nodes 140, 140 ', 140 ". End nodes 144 , 146, 144 ', 146', 144 ", 146" may be, for example, wireless communication devices or terminals, and access nodes 140,140 ', 140 "may be, for example, access routers or wireless base stations. . The exemplary communication system 100 also includes a number of other nodes 104, 106,109, 110 and 112, used to provide interconnectivity or perform specific services or functions. Specifically, the exemplary communication system 100 includes a Server 104, used to support the transfer and storage of states concerning the end nodes. Server node 104 may be an AAA server, or may be a Context Transfer Server, or may be a server that includes both AAA server functionality and a Context Transfer server functionality.

In the exemplary system 100 of Figure 1 is shown a network 102 including Server 104, Source Agent node 109 and node 106, all connected to an intermediate network node 110 by a corresponding network link 105,108 and 107, respectively. Intermediate network node 110 in network 102 also provides interconnectivity to network nodes that are external from network perspective 102 through network link 111. Network link 111 is connected to another intermediate network node 112, which provides additional connectivity to a plurality of nodes. 140, 140 ', 140 "through network links 141, 141', 141", respectively.

Each access node 140, 140 ', 140 "is shown as providing connectivity to a plurality of N-nodes (144, 146), (144', 146 '), (144", 146 "), respectively, by means of links. 145, 147 ', 145', 147 '), (145 ", 147"), respectively. In the exemplary communication system 100, each access node 140, 140', 140 "is shown using wireless technology, such as wireless links to provide access. A radio coverage area, such as the communication cell 148, 148 ', 148 "of each access node 140, 140', 140", respectively, is shown as a circle around the corresponding access node.

The exemplary communication system 100 is then used as a basis for describing various embodiments of the invention. Alternative embodiments of the invention include various network topologies, wherein the number and type of network nodes, the number and type of access nodes, the number and type of end nodes, the number and type of Servers and Originating Agents or others. Agents, the number and type of links, and the interconnectivity between nodes may differ from this of the example communication system shown in Figure 1.

In various embodiments of the present invention, some of the functional entities shown in Figure 1 may be omitted or combined. The location or placement of these functional entities on the network may also vary.

Figure 2 shows a detailed illustration of an exemplary end node 200, such as a movable node, implemented in accordance with the present invention. Exemplary end node 200, shown in Figure 2, is a detailed representation of equipment that can be used as any of the end nodes 144, 146, 144 ', 146', 144 ", 146" shown in Figure 1. In the embodiment of Figure 2 , the riophinal 200 includes a processor 204, a wireless communication interface 230, a shrine input / output interface 240, and a memory 210 coupled by a bus206. Accordingly, via bus 206 the various components of the end node 200 can exchange information, signals and data. Components 204, 206, 210, 230, 240 end donor 200 are located within housing 202.

Wireless communication interface 230 provides a mechanism by which internal components of end node 200 can send and receive signals to external devices and network nodes, such as access nodes. Wireless communication interface 230 includes, for example, a receiving circuit 232 with a corresponding receiving antenna 236 and a transmitting circuit 234 with a corresponding transmit antenna 238 used to couple end node 200 to other network nodes, for example through The exemplary end node 200 also includes a user input device 242, such as a keyboard, and a user output device 244, such as a display, which are coupled together. to bus 206 can via means of the user input / output interface 240. Thus, the user input / output devices 242, 244 can exchange information, signals and data with other end node 200 components via user input / output interface 240 and of the bus206. User input / output interface 240 and associated devices 242, 244 provide a mechanism by which the user can operate end node 200 to perform various tasks. In particular, user input device 242 and user output device 244 provide functionality that allows the user to control end node 200 and applications, such as modules, programs, routines, and / or functions, which are executed in memory. 210 from end node 200.

Processor 204 under the control of various modules, such as routines, included in memory 210, control the operation of end node 200 to perform various signaling and processing, as discussed below. Modules included in memory 210 are executed at startup or when called by other modules. Modules can exchange data, information and signals when executed. Modules can also share data and information when executed. In the embodiment of Figure 2, memory 210 of end node 200 of the present invention includes a signaling / control module 212 and signaling / control data 214.

The signaling / control module 212 controls the generation and processing of signals relating to reception and sending signals, such as messages, storage management, retrieval, and processing of state information. Messages stored in memory 210 include a connection request message 610, a connection response message 660, an IP 800 registration message, and an IP 900 registration response message. The 800 and 900 messages may be small, small, for example, smaller than conventional IPv4 and / or Mobile IPv6 messages. Messages stored in memory may be messages that are generated and / or received. The messages will be discussed in more detail below. The signaling / control data 214 includes state information, such as parameters, status, and / or other information regarding end node operation. In particular, signaling / control data 214 may include configuration information 216, such as end node identification information, and operational information 218, such as current processing state information, pending response status, and so on. Module 212 may access and / or modify data 214, such as updating configuration information 216e and / or operating information 218.

Figure 3 shows a detailed illustration of an exemplary access node 300 implemented in accordance with the present invention. The exemplary access node 300, shown in Figure 3, is a detailed representation of an equipment that can be used as any of the access nodes 140, 140 ', 140 "shown in Figure 1. In the embodiment of Figure 3, access node 300 includes a processor 304, a memory 310, a network / interconnect interface 320, and a wireless communication interface 330 coupled by bus 306. Accordingly, via bus 306 the various components of access node 300 may exchange information, signals and data. Components 304, 306, 310,320, 330 of access node 300 are located within housing 302.

Network / interconnect interface 320 provides a mechanism by which internal components of access node 300 can send and receive signals to / from external devices and network nodes. Network / interconnect interface 320 includes a receiver circuit 322 and a transmitter circuit 324 used to couple node 300 to other network nodes, such as by means of copper wires or fiber optic lines. Wireless communication interface 330 also provides a mechanism by which internal components of access node 300 can send and receive signals to / from external devices and network nodes, such as end nodes. Wireless communication interface 330 includes, for example, a receiver circuit 332 with a corresponding receive antenna 336 and a transmitter circuit 334 with a corresponding transmit antenna 338. Interface 330 is used to couple access node 300 to other network nodes, such as via wireless communication channels.

Processor 304 under the control of various modules, such as routines, included in memory310, controls the operation of access node 300 to perform various signaling and processing. Modules included in memory 310 are executed at startup or when called by other modules that may be present in memory 310. Modules can exchange data, information, and signals when executed. Modules can also share data and information when executed. In the embodiment of Figure 3, the memory 310 of the access node 300 of the present invention includes a State Management module 312 and a Signaling / Control module 314. Corresponding to each of these modules, memory 310 also includes State Management data 313 and data. 315. The messages stored in memory 310 include a connection request 610 message, a 660 disconnect response message, an IP 800 registration message, and an IP 900 registration response message. Messages 800 and 900 may be messages of the invention. small, for example, which are smaller than conventional Mobile IPv6 and / or IPv6 messages. Memory 310 also includes an IPv6 Mobile and / or IPv6 Mobile680 log message. Messages stored in memory may be messages that are generated and / or received. The messages will be discussed in more detail below.

State Management Module 312 controls the processing of signals received from end nodes or other network nodes for state storage and retrieval. State Management Data 313 includes, for example, end-node-related information, such as the state or part of the state, or current state allocation of the end node if stored on any other network node. State Management module 312 may access and / or modify State Management data 313.

The 314 Signaling / Control module controls signal processing to / from end nodes via wireless communication interface 330, and to / from other network nodes via network / interconnect interface 320, which is required for other operations such as wireless function. basic, network management, etc. The 315 Signaling / Control data includes, for example, end-node related data regarding wireless channel assignment for basic operation, and other related data such as the address of the support / management servers, configuration information for basic network communications. . The 314 Signaling / Control module can access and / or modify 315 Signaling / Control data.

Figure 4 shows a detailed illustration of an exemplary Server 400 node implemented in accordance with the present invention. The exemplary Server node 400, shown in Figure 4, is a detailed representation of an equipment that can be used as Server 104 shown in Figure 1. In the embodiment of Figure 4, Server node 400 includes a 404 processor, a 410 memory, and a network interface. 420, coupled by bus 406. Therefore, through bus 406, the various components of access node 400 can exchange information, signals and data. Components 404, 406, 410, 420 of access node 400 are located within housing 402. 1

Network / interconnect interface 420 provides a mechanism whereby internal components of Server400 node can send and receive signals to / from external devices and network nodes. Network / interconnect interface 420 includes a receiver circuit 422 and a transmitter circuit 424 used to couple node 400 to other network nodes, such as by means of copper wires or fiber optic lines. >

Processor 404 under the control of various modules, such as routines, included in memory410, controls the operation of Server 400 to perform various signaling and processing. Modules included in memory 410 are executed at startup or when called by other modules that may be present in memory 410. In Figure 4 mode, the 410 memory of Server 400 of the present invention includes a Core State Management module 412 and Core State Management data. 413, and an AAA module 415.

Core State Management Module 412 controls the processing of signals received from other Servers, access nodes, or network nodes for state storage and retrieval. Core State Management Data 413 includes, for example, end node state information. Core State Management 412 module can access and / or modify Core State Management 413 data.

The AAA 415 module performs authentication, authorization, and accounting operations.

Figure 5 shows an exemplary Source Agent node 500 implemented in accordance with the present invention. The exemplary Source Agent node 500 may be used in the systems of Figure 1, such as the source agent node 109, which functions as a Source Agent. In the embodiment of Figure 5, source agent node 500 includes an input / output interface 501, a processor 503, and memory 507 coupled by bus 502. Elements 501, 502, 503, and 507 of source agent node 500 are located within the housing 508, such as a plastic and / or metal box, represented by the rectangle around the inner elements 501, 502,503 and 507 of the node. Accordingly, via bus 502 the various components of access node 500 can exchange information, signals and data. The input / output interface 501 includes a circuitry used to couple node 500 to other network nodes, such as by half fiber optic lines, and potentially to end nodes, for example by means of communication channels. The 503 processor under the control of various modules, such as routines, included in memory507, controls the operation of source agent node 500 to perform various signaling, routing, and other operations, as discussed below. Modules included in memory 507 are executed at startup or when called by other modules. Modules can exchange data, information and signals when executed. Modules can also share data and information when executed. In the embodiment of Figure 5, the source agent node memory 507 of the present invention includes a mobility agent module 506 that includes, for example, parameters, endpoint communication and / or status information, security information, and / or other information regarding the interaction and / or communication of the end node with an access node and / or other device. Mobility Agent module 506 also includes end-node-specific state that includespaths between source addresses and end-node temporary addresses.

Mobility agent module 506 allows node 500 to support mobility management services and end node connectivity. Thus, the originating agent node 500 is capable of providing node mobility, session establishment, and session maintenance services to the connected end nodes. The mobility agent module 506 can be implemented in many ways. In Figure 5 mode, it is implemented with a collection of submodules. As illustrated, the mobility agent module 506 includes a Mobile IPv4 submodule 505 and a Mobile IPv6 submodule 504. By including the submodules 505 and 504, the mobile agent module 506 is capable of supporting multiple versions of IP signaling. Mobile including Mobile IPv4 and IPv6 Mobile signaling. In various embodiments, the mobility agent module 506 includes a subassembly of submodules 505 and 504 shown in Figure 5. For example, in instances where Mobile IPv6 is not required, Mobile IPv6 Source Agent submodule 504 may be omitted. .

Figure 6 shows an exemplary reduced size IP log message 800 implemented in accordance with this invention. Message 800, while sufficient for the purposes of establishing network layer connectivity and redirecting Mobile IP tunnels, as shown in the invention, is smaller in size than even the smallest IPv4Mobile Registration Request message shown in the section. of prior art description. An exemplary 800 small-size IP record message includes: a Message Type 810 field, a reserved field 820, a "D" (Unregistration) 830 field, an "I" (Initial) field 840, a Message Identifier 850, and zero or more Optional extensions 860.

The Message Type 810 field includes a value that identifies the message as a reduced IP log message. In some embodiments of this invention, the value of the message type field identifies the message as a Mobility Management Protocol message referred to as Registration Request message3.

Reserved field 820 is reserved for structure use. In one embodiment of this invention, the value of the reserved field 820 is set to zero by the sender and is ignored by the receiver.

The "D" (Unregister) field 830 includes a value that indicates whether this message is sent to register a network layer or unregister a previously registered network layer.

Field "I" (Initial) 840 includes a value indicating whether this message is the initial registration message for this network layer or a subsequent registration for a previously established network layer.

Message Identifier 850 includes a value that distinguishes message 800 from at least one other message of the same type (message 800) sent before it. In some exemplary embodiments of this invention, Message Identifier field 850 employs the values of a monotonically increasing sequence number. In other exemplary embodiments of this invention, Message Identifier field 850 employs the values of a time stamp. In still other exemplary embodiments of this invention, Message Identifier field 850 is comprised partly of a sequence number and partly of a timestamp.

Zero or more Optional 860 extensions may be included, which may include several additional parameters. In some exemplary embodiments of this invention, such extensions include the Target Access Node Identifier 870 extension, which identifies the access node to which the message 800 is sent (for example, the target access node 530 in Figure 8), the Access Identifier extension. last access node 880, which identifies the access node with which the end node sending message 800 (for example, end node 510 in Figure 8) was last connected at the network layer (for example, access node 520 in Figure 8) and an authenticator extension 890 which authenticates message 800. In some exemplary embodiments of the invention, each of extensions 870 and 880 includes at least one Type field whose value identifies the extension type, a Length field whose value identifies the length of the extension. and an Identifier field, whose value identifies a target access node and the last access node. In some such embodiments of the invention, authenticator extension 890 includes at least one Type field whose value identifies the extension type, a Length field whose value identifies the extension length, and an Authenticator field whose value authenticates the cryptographically message; The authentication field value calculated based on a shared key between the sender and receiver. In some exemplary embodiments of this invention, the identifier extension 880 of the last access node is not included when the "I" field value 840 indicates that message 800 is an initial record, while the identifier extension 880 of the last access node is included when the value from field "I" 840 indicates that message 800 is not an initial record. In some embodiments of this invention, the authenticator extension 890 is an optional extension, so that it can be omitted from message 800. Various combinations of optional extensions are possible, according to various embodiments of the invention, including zero, one, two, or three extensions 890.

In an exemplary embodiment of this invention, Message Type 810 field is 8 bits long, reserved field 820 is 14 bits long, field "D" 830 is an indicator of 1 bit length, field "I" 840 is a 1-bit indicator, Message Identifier 850 consists of a 16-bit sequence number and a 32-bit timestamp. In the same embodiment of this invention, as for the optional extensions, the target access node identifier 870 and the last access node identifier 880 are included in message 800, each consisting of an 8-bit type field, a field of length 8 bits and a 64-bit name identifier. In the same embodiment of this invention, when the optional authenticator extension 890 is included in message 800, it comprises an 8-bit type field, an 8-bit length field, and a 64-bit maximum authenticator. In the same embodiment of this invention, the maximum length of a shortened IP log message 800 is 312 bits, which is significantly smaller than the smallest possible Log Request message according to MIPv4, which in the section of the prior art description is shown to be 592 bits in length.

Figure 7 shows an exemplary small size IP record response message 900 implemented in accordance with this invention. Message 900, although sufficient for the purpose of establishing network-layered connectivity and Mobile IP tunnel redirection, as shown in the invention, is smaller than even the smallest possible Mobile IPv4 Registration response message shown in the description section of the prior art. The exemplary smallest 900 IP Record response message includes: a Message Type 910 field, a Message Identifier 920 field, a Response COdig1Ode field 930, a Reserved 940 field, a Lifetime Temp field 950, and zero or more Optional Extensions 960.

Message Type field 910 includes a value that identifies the message as a small IP log response message. In some embodiments of this invention, the value of the Message type field identifies the IP 900 Record Response Message as a Mobility Management Protocol message referred to as Record ReplyL3 message. Message Identifier 920 includes a value that equals message 900 with a message. corresponding small IP address 800. In some embodiments of this invention, Message Identifier field 920 employs the values of at least part of the Message Identifier field value 850 and the corresponding short-size IP record message 800, message 900 that responds to Reply Code field 930 includes a value that indicates successful or failed IP registration operation.

Reserved field 940 is reserved for structure use. In some embodiments of this invention, the valued reserved field 940 is set to zero by the sender and is ignored by the receiver.

The 950 Lifetime field includes a value that indicates the lifetime of the IP record. In some embodiments of this invention, the lifetime value 950 corresponds to the lifetime of an IP address associated with the message receiver 900. In some such embodiments of the present invention, the message receiver 900 must send another shortened IP log message that has the value of the 950 Lifetime field expires upon receipt of message 900.

Zero or more Optional 960 extensions may be included, which may include several additional parameters. In some embodiments of this invention, such extensions include an Originating address extension 970, which is an IP address associated with the message receiver 900 (e.g., the endpoint IP address 510 in Figure 8)., An Agent Address extension 980, which identifies the Mobile IP Source Agent address that preserves the Source Address included in extension 970 and an authentication message 900 of authenticator extension990. In some exemplary embodiments of the invention, each of extensions 970 and 980 includes at least one Type field whose value identifies the extension type, a Length field whose value identifies the extension length, and an Address field whose value represents an IP address. . In some of such embodiments of the invention, authenticator extension 990 includes at least one Type field whose value identifies the extension type, a Length field whose value identifies the extension length, and an Authenticator field whose value authenticates the cryptographically message; The authentication field value calculated based on a shared key between the sender and receiver. In some exemplary embodiments of this invention, the source address extension 970 and the source agent address extension 980 are included only when the value of the "I" field 840 of the small size IP record message 800 corresponds, message 900 is in response to, indicate an initial registration, while the source address extension 970 and the source agent address extension 980 are not included when the value of the "I" field 840 in the reduced-size IP log message 800, the message 900 responds to, indicate a subsequent record. Several combinations of optional extensions are possible according to various embodiments of the invention, including zero, one, two or three of extensions 970, 980, 990.

In an exemplary embodiment of this invention, Message Type 910 is 8 bits long, Message Identifier 920 is comprised of a 16 bit sequence number, Response Code 930 field is 8 bits long, Reserved field 94 0 is 8bits in length and the Lifetime field 950 is 16 bits in length. In the same embodiment, when the source address 970 and optional source address 980 of the optional extensions are included in message 900, each consisting of an 8-bit type field, an 8-bit length field, and an IP address of no. maximum 32 bits. In the same embodiment, when the optional authenticator extension 990 is included in message 900, it comprises an 8-bit type field, an 8-bit length field, and a maximum of 64-bit authenticator. In the same embodiment of this invention, the maximum length of a 900 small size IP log response message is 232 bits, being significantly smaller than the smallest possible log response message according to MIPv4, which section of the prior art description is shown as follows. 560 bits in length.

Figure 8 shows an exemplary signaling according to exemplary embodiments of the invention. The signaling is shown in the context of the exemplary system 100 shown in Figure 1. End Node 510 corresponds to 'any end nodes 144, 146, 144', 146 ', 144 ", 146" of exemplary system 100 and is implemented in accordance with the implementation of exemplary end node 200 of Figure 2; Access Node 520 and Target Access Node 530 are simplified implementations of exemplary access node 300 of Figure 3 and correspond to any of the access nodes 140, 140 ', 140 "of exemplary system 100 of Figure 1. Server 540 is an implementation simplified representation of Server 400 in Figure 4e corresponds to Server 104 on exemplary system 100 in Figure 1. Source Agent Node 550 is a simplified representation of source agent 500 in Figure 5 and corresponds to source agent node 109 in system 100example in Figure 1 In Figure 8, the vertical solid lines 511,521, 531, 541, and 551 represent nodes 510, 520, 530, 540, and 550 in time, where the parts of lines 511, 521, 531, 541, and 551 at the top of Figure 8 represent a time. preceding all parts of the lines at the base of Figure 8. The horizontal solid lines 610, 620, 640, 660, 670, 680, 690, 700,710 and 720 represent signals between nodes 510, 520, 530,540 and 550. The wide double arrow lines 600, 630 and 650 represent signal groups exchanged between nodes 510,520, 530, 540 and 550. Dashed lines 621 and 641 represent alternative signals to signals 620 and 640. Dotted lines 630 and 650 represent optional signals. A signal is transmitted between two nodes if the line represents such. A signal or group of signals indicates a vertical line point representing the node in time. Signal 610, for example, is transmitted at time 610a by end node 510e is received by target access node 530 at time 610c.

The establishment of the Physical Layer will now be described. In Figure 8, end node 510 at point 600 transmits a signal, part of signal group 600, to target access node 530 requesting access from physical layer 530. Target access node 530 receives the signal, part of signal group 600 at point 600c and transmits another signal, part of signal group 600, to end node 510, granting the physical layer access to end node 510.

The establishment of the Link Layer will now be described. End node 510 at point 610a transmits a Connection Request message 610 to target access node 530, requesting the establishment of link and communications from the medium access control layer with target access node 530. In some exemplary embodiments of the invention, Connection Request 610 includes a first identifier, which identifies end node 510. In some embodiments of this invention, message 610 also includes a second identifier, which identifies the access node to which end node 510 had previously established connection, such as access node 530. Target access node 530 receives a Connection Request message 610 at point 610c in which the parameters (e.g. identifiers) included in message 610 are stored in memory of target access node 530. In other exemplary embodiments of this invention, Message 610 is a Handoff Request message indicating that endpoint 510 had this previously established communication with this or another access node (for example, access node520).

An exemplary Core Context Transfer mode will be described. At point 620c, node 530 transmits State Request message 620 to server 540 requesting authorization and another state corresponding to end node 530. State Request message 620 includes at least some of the parameters stored at point 610c in node 530 memory, such as, for example, endpoint identifier 510. Server 540 receives the State Request message 620 at point620d and searches its memory for the state associated with endpoint510. In some exemplary embodiments of the invention, where server 540 is a core state transfer server, server 540 transmits a state response message 640 at point 640d, which includes an authorization state and another state (such as security keys). , IP addresses, and other parameters) associated with end node 510. Target node 530 receives message 640 at point 640c and stores in its memory at least part of the state associated with end node 510 that is included in message 640. An AAA server mode will be described. In some other exemplary embodiments of this invention, where server 540 is an authentication and authorization server (AAA), server 540 transmits a message, part of an optional message group 630, at 630d requesting proof of identity of end node 510. Node 510 receives the message, part of message group 630, at point 630a and transmits the proof of identity message, part of message group 630, to Server 540. In some embodiments of this invention, server 540 and end node 510 exchange additional messages. which prove the identity of endpoint 510 and server 540 to each other. When server 540 is satisfied with endpoint identity 510 at point 640d, it sends a message 640, which includes the authorization state and another state (such as , security keys, IP addresses, and other parameters) associated with endpoint 510. Target access node530 receives message 640 at 640c and stores in its memory at least part of associated with the final node510 that is included in message 640.

An exemplary Non-Hierarchical Context Transfer mode will be described. In some exemplary embodiments of the invention, instead of message 620, target access node 530 sends a message 621, at point 621c, access node 520; access node 520 being the last access node to which end node 510 had a connection. Message 621 according to this invention includes at least some of the parameters stored in node memory 630c of node 530, such as the node identifier 510. Access node 520 receives message 621 at point 621b and searches its memory the state associated with endpoint 510. Access node 520 transmits a response message 641 at point 641b, which includes the authorization state and other state (such as security keys, IP addresses, and other parameters) associated with end node 510. target node 530 receives message 641 at point641c and stores in its memory at least part of the state associated with end node 510 that is included in message641.

An optional safety association step used in some embodiments of the present invention will now be described. In some embodiments of this invention, where data traffic encryption is required through the link between end node 510 and target access node 530, node 530 transmits a message, part of an optional message group 650, at point 650c, to establish at least one encryption key with end node 510. Node 510 receives the message, part of message group 650, at point 650a and transmits a key-setting message, part of message group 650, to target access node 530 In some inventive embodiments, target access node 530 and end node 510 exchange additional messages to establish the decryption key.

The completion of the Link Layer establishment will now be described. Target access node 530, at point 660c, sends Connection Reply message 660, giving the physical layer at least access to end node510. End node 510 receives message 660 at point 660a. In the embodiment of this invention, in which message 610 is a Handoff request message, message 660 is a Handoff Reply message.

The establishment of the Network Layer will now be described. End node 510 conditions in its memory and transmits a small-sized IP log message 670 at point 670a to target access node 530 requesting network layer establishment with and packet redirection via node 530. In some embodiments of the invention , the small-size IP log message 670 is implemented according to the invention in accordance with message type 800 of Figure 6. Target access node 530 receives message 670 at point 670c and stores the values of at least some of the fields included in the message. 670 in your memory. Target access node 530 conditions an IPMobile 680 registration message and transmits it at point 680c to the originating agent 550. According to this invention, the IPMobile 680 registration request message ID field includes at least a portion of the IPID Mobile ID field. Messages 850 from message 800 of Figure 6.

An initial registration mode will now be described. In an exemplary embodiment of this invention, the reduced size IP record message 670 implemented according to message 800 of Figure 6, field "I" 840 indicates the initial record. In this embodiment of the invention, the target access node 530 conditions a Mobile IP registration message 680 and transmits it at point 680c to the originating agent 550. For the construction of the Mobile IP Registration Request message 680, the target access node 530 combines the state associated with end node 510 with the state received at point 640c of server 540. In one embodiment of this invention, where server 540 is an AAA server, the state associated with end node 510 that is stored on node 530 includes a source address and address address values. source agent associated with end node 510, allowing the source address and source agent address values to be zero. In one embodiment of this invention, the originating agent address included in the stored state is not zero and target access node 530 uses the value as part of the corresponding field of the IPMobile 680 registration request message. In another embodiment of this invention, the agent address source state included in the stored state equals zero and target access node 530 uses a locally configured source agent address value as a corresponding part of the Mobile IP registration request message 680. In another embodiment of this invention, the source address included in the stored state is not zero and target access node 530 uses the corresponding part value of Mobile IP registration request message 680. In an additional embodiment of this invention, the source address included in the stored state is equal to zero and the access node target 530 uses the zero value as the corresponding field message message field Mobile IP 680 quote.

Originating Agent 550 conditions and transmits the registration response message 710 at point 710e to grant the registration request received previously. Target access node 530 receives log response message 710 at point 710c and stores at least part of the values included in message fields 710 in its memory. Node 530 conditions in memory and transmits at point 720c a reduced-size IP registration message 720 so as to grant the network layer request to endpoint 530. In this exemplary embodiment of the invention, the reduced-size IP response message 720 is implemented according to message type 900 of Figure 7. In this embodiment of the invention, Message Identifier field 920 of message 900 in Figure 7 is copied from the corresponding Message Identifier included in Message Identifier field 850 of Figure 800 in Figure a6. message transmitted in response, the source address value included in message 710 of source agent 550 that is used as part of the value of source address extension 970 of message 900 in Figure 7, the Lifetime value included in message 710 is used as the upper limit for the value of the Life Time field 950 of message 900 in Figure 7, and the value of Address Source Agent address included in message710 is used as part of the value of Source Agent Address 980 extension of message 900 in Figure 7.

A subsequent registration mode will now be described. In an exemplary embodiment of this invention, the reduced size IP record message 670 implemented according to message 800 in Figure 6, field "I" 840 indicates a non-initial record. According to one embodiment of the invention discussed in Figure 6, in a non-initial record message 800, the identifier extension of the last access node 880 is included in the message 800. According to this invention, the identifier of the last access node is fixed at an identifier that identifies access node 520.

In this embodiment of the invention, target access node 530 conditions Mobile IP registration message 680 and transmits at point 680c to originating agent 550. For the construction of Mobile IP Registration Request message 680, target access node 530 combines state associated with end node 510 with the state received at point 640c of server 540. In one embodiment of this invention, where server 540 is a Core Context Transfer server, the state associated with end node 510 that is stored at node 530 includes a source address and source agent address values associated with end node 510. In one embodiment of this invention, target access node 530 uses the source address and source agent address values as part of the corresponding Mobile IP registration request message field 680.

Target access node 530 also constructs a Mobile IP registration message 690 and transmits it at point 690c to access node 520, which is identified in the last access node identifier extension of message 670. Access node 520 receives message 690 at point 690b and transmits a reply message 700 at point 700b. Target access node 530 receives message 700 at point 700c. In another embodiment of this invention, messages 690 and 700 are link-update messages, while in another non-invention mode, there are other package redirection messages. According to this invention, message 690 identifies at least end node 510. In one embodiment of this invention, the identifier is the IP address (source address) of end node 510.

Originating Agent 550 conditions and transmits the registration response message 710 at point 710e to grant the registration request received previously. Target access node 530 receives log response message 710 at point 710c and stores at least part of the values included in message fields 710 in its memory. Node 530 conditions in memory and transmits at point 720c the reduced-size IP registration response message 720 so as to grant the network node registration request to end node 510. An exemplary embodiment of this invention is the reduced-size IP registration response message. 720 is implemented according to message type 900 of Figure 7. In this embodiment of the invention, Message Identifier field 920 of message 900 in Figure 7 is copied from the corresponding Message Identifier included in Message Identifier field 850 of Figure 800 of which This message 720 is being transmitted in response to and the lifetime value included in message 710 is used as the upper limit for the lifetime value field 950 of message 900 in Figure 7. In this embodiment of the invention, the original address extensions and source agent address 970 and 980 of Figure 7 are not included in message 720.

In an exemplary embodiment of this invention, end node 510 communicates with target access node 530 as shown in Figure 8, while end node 510 has no other physical layer, link, or network connection established with the same or different access node. In another exemplary embodiment of this invention, end node 510 communicates with target access node 530 as shown in Figure 8, while end node 510 has at least one more physical, link or network layer connection established with the same or different access node. , such as access node 520.

In various embodiments, the nodes described herein are implemented using one or more modules to perform steps corresponding to one or more methods of the present invention, such as signal processing, message generation and / or transmission steps. Thus, in some embodiments various aspects of the present invention are implemented using modules. Such modules may be implemented using software, hardware or a combination of software and hardware. Many of the methods or method steps described above can be implemented using machine executable instructions, such as software, included in a machine readable medium, such as a memory device, such as RAM, a floppy disk, etc., to control a machine, such as a general purpose computer with or without additional hardware, to implement all or parts of the methods described above, such as one or more nodes. Accordingly, among other things, the present invention relates to a machine readable medium that includes machine executable instructions for causing a machine, such as a processor and associated hardware, to perform one or more of the steps of the method (s). (s) described above.

Numerous further variations in the methods and equipment of the present invention described above will be apparent to those skilled in the art in view of the above description of the invention. Such variations should be considered within the scope of the invention. The methods and equipment of the present invention may be, and in various embodiments, are used with CDMA, Orthogonal Frequency Division Multiplexing (OFDM), or various other technical types of communication that may be used to provide wireless communication links between access nodes. and we furniture. In some embodiments, access nodes are implemented as base stations that establish communication links with mobile nodes using OFDM and / or CDMA. In various embodiments, mobile nodes are implemented as portable computers, personal data assistants (PDAs) or other portable devices including receiver / transmitter and logic circuits and / or routines to implement the methods of the present invention.

Claims (20)

1. Method for operating a base station, the method comprising: - receiving a small Mobile IP registration message; e- generate from the small Mobile IP log message at least one of an IPv4 Mobile or IPv6 Mobile log message. The method according to claim 1, wherein receiving a reduced Mobile IP registration message includes receiving the registration message via an air link. The method according to claim 2, wherein the reduced size Mobile IP log message includes a base station identifier that identifies the base station. A method according to claim 2, the method further comprising: storing prior to receiving the small Mobile IP log message, the status information that corresponds to the wireless terminal, the status information including at least one of a Source Address , a Source Agent Address, and wireless terminal profile information. The method of claim 4, further comprising, prior to the storing step, receiving at least one of an Originating Address, an Originating Agent Address, and wireless terminal profile information from another node that is different from the terminal. wireless. A method according to claim 4, which generating at least one of an IPv4 Mobile and IPv6 Mobile log message includes generating a log message that includes a Source Agent Address value that was not included in the IPMobile log message size. reduced. The method of claim 6, wherein generating at least one Mobile eIPv6 Mobile IPv4 log message also includes including a Source Agent Address value, the Source Address value being a stored Source Agent Address value that received from the additional node. The method according to claim 7, wherein the Source Address value is zero when the stored information corresponding to the non-phoned terminal includes a non-zero Source Address value. The method of claim 6, wherein generating at least one of a Mobile and ΙΡνβ Mobile IPv4 registration message also includes incorporating a Temporary Address, which identifies the base station, into a generated Mobile IPv4 and Mobile IPv6 registration message. A method according to claim 9, wherein the small Mobile IP log message includes a message identifier, the message identifier including at least one of a matching number and a timestamp. The method of claim 10, wherein the message identifier includes the offset number and the timestamp. A method according to claim 5, wherein the other node that is different from the wireless terminal node is an authentication and authorization server. A method according to claim 5, wherein the other node that is different from the wireless terminal node is another base station to which the wireless terminal has previously been connected. A base station, comprising: - a receiving module for receiving a small Mobile IP logging message, - a signal generation module for generating a small Mobile IP logging message for at least one of a Mobile IPv4 or Mobile IPv6 log message . The base station of claim 14, wherein the receiver module is a radio receiver module for receiving the registration message via an interleaver. A base station according to claim 15 further comprising: a memory for storing the small size Mobile IP log message, the memory including a small size Mobile IP log message that includes a base station identifier that identifies the station. base. The base station of claim 15, wherein the memory also includes: status information corresponding to wireless terminal, status information including at least one of an Origin Address, an Origin Agent Address, and information wireless terminal profile profile. A base station according to claim 17, further comprising: a network interface for receiving at least one of an Originating Address, an Originating Agent Address, and other wireless terminal profile information that is different from one another. of the wireless terminal. The base station of claim 17, wherein the signal generation module includes means for accessing stored state information to retrieve from the stored state information a Source Agent Address value that has not been included in the Small Mobile IP registration message, but which will be included in at least one of a Mobile IP IPv4 or IPv6 registration message to be generated from a small Mobile IP registration message. The base station of claim 19, wherein the signal generation module also includes means for obtaining a Source Agent Address value that has been received from the additional node of the stored information for inclusion in at least one of an IPv4 log message. Mobile or IPv6 Mobile to be generated.