HK1110722A - Connection setup using flexible protocol configuration - Google Patents

Description

Connection establishment using flexible protocol configuration

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The benefit of U.S. provisional application No.60/638,471 entitled "CONNECTION SETUP USING FLEXIBLE procedure configuration CDMA", filed on 22.12.2004, this provisional application being incorporated herein by reference in its entirety.

Technical Field

[0001] The present invention relates generally to communications, and more specifically to techniques for establishing connections in a communication system.

Background

[0002] In a communication system, a user terminal communicates with an access point in order to obtain various services such as voice, packet data, and the like. Typically, a session is established for a user terminal in order to facilitate communication. As part of session establishment, the user terminal and the access point may negotiate various configurable protocols and select parameters for these protocols. A session is generally considered to be a collection of information, such as protocols, security keys, user capabilities, etc., that is used for communication between a user terminal and an access point. Thus, the terms "session" and "session information" are often used interchangeably.

[0003] For proper operation, the configured protocols need to be synchronized at the user terminal and the session holding access point, which is the access point currently holding a session for the user terminal. The user terminal may be mobile and in the power saving mode, the user terminal may move from the coverage area of the session holding access point to the coverage area of the new access point. If the user terminal subsequently enters the active mode under the coverage of the new access point (e.g., due to a user-initiated call or page from the system), the user terminal may attempt to communicate with the new access point. However, the new access point is typically unaware of the configured protocol used by the user terminal. Typically, communication with a new access point is only started after a session for a user terminal has been retrieved from the session holding access point or a new session has been established with the new access point.

[0004] The new access point may obtain the previously established session for the user terminal in several ways. In one method, a user terminal provides an address of a session maintenance access point for a new access point. Subsequently, the new access point retrieves the session from the session holding access point. In another approach, the user terminal sends the entire list of configured protocols (or parameters set to non-default values) to the new access point. The new access point then establishes an appropriate protocol based on the information received from the user terminal. For both methods, retrieving the session from the session holding access point or receiving the session information from the user terminal incurs a delay. Furthermore, sending session information from the session holding access point or user terminal to the new access point consumes system resources.

[0005] Accordingly, there is a need in the art for techniques for efficiently establishing a connection between a user terminal and an access point.

Disclosure of Invention

[0006] Techniques for connection establishment using flexible protocol configurations are described herein. The session information for the user terminal is divided into classes, for example, into two classes called user-specific session information and modem configuration information. The user-specific session information includes information such as security keys and address information specific to the user terminal. The modem configuration information includes information for a radio connection.

[0007] A limited number of modem-specific configurations may be defined and made available for use in a communication network. Each modem-specific configuration is associated with specific modem configuration information that indicates (1) protocol versions for layers of the air interface protocol stack, and (2) parameter values for those protocol versions. Each allowed modem-specific configuration is assigned a different token that uniquely identifies the modem-specific configuration.

[0008] The user terminal initially establishes a session with the first access point and obtains at least one token associated with its modem configuration information. Thereafter, the user terminal may establish a connection with the second access point by sending a token instead of modem configuration information. The second access point receives a token sent by the user terminal and obtains modem configuration information associated with the token. The second access point then initializes the air interface protocol stack with the modem configuration information and obtains a modem-specific protocol stack for the user terminal. The second access point then sends a response back to the user terminal to indicate a successful connection establishment. Thereafter, the user terminal and the second access point communicate according to a modem-specific protocol stack for the user terminal. The second access point may allow the user terminal to access some limited functionality until the session for the user terminal is resumed.

[0009] The second access point may attempt to retrieve the session for the user terminal from the first access point. If this is successful, the second access point updates the protocol stack with the retrieved session information in order to obtain a complete protocol stack for the user terminal. Thereafter, the user terminal and the second access point communicate with the complete protocol stack, e.g. exchange of protected data using the security key.

[0010] Various aspects and embodiments of the invention are described in more detail below.

Drawings

[0011] The features and characteristics of the present invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which like reference characters identify correspondingly throughout.

[0012] Fig. 1 illustrates a wireless communication network;

[0013] FIG. 2 illustrates an exemplary air interface protocol stack;

[0014] FIG. 3A illustrates the partitioning of session information;

[0015] FIG. 3B illustrates a protocol stack for a connection;

[0016] FIG. 4 illustrates a process for establishing a connection using a token;

[0017] fig. 5 shows a process for communication by a target access point;

[0018] fig. 6 shows a procedure for communication by a user terminal;

[0019] FIGS. 7A and 7B illustrate a process for establishing a connection for a user terminal;

[0020] fig. 8 shows the communication between a user terminal and an access point;

[0021] FIG. 9 illustrates an air interface protocol stack for the communications in FIG. 8;

[0022] fig. 10 shows a block diagram of a user terminal and an access point.

Detailed Description

[0023] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0024] Fig. 1 shows a wireless communication network 100 with multiple access points supporting communication for multiple user terminals. For simplicity, only one user terminal 110 and 3 access points 120a (AP0), 120b (AP1), and 120c (AP2) are shown in fig. 1. An access point is typically a fixed station used for communicating with the user terminals and may also be referred to as a base station, a Base Transceiver System (BTS), a node B, or some other terminology. A User Terminal (UT) may be fixed or mobile and may also be referred to as an Access Terminal (AT), a Mobile Station (MS), a User Equipment (UE), a wireless device, a handset, or some other terminology. A user terminal may communicate with one or more access points on the forward link and/or reverse link at any given moment. The forward link (or downlink) refers to the communication link from the access points to the user terminals, and the reverse link (or uplink) refers to the communication link from the user terminals to the access points.

[0025] As described above, a session is a collection of information such as security keys, protocols and/or protocol versions, protocol states, user capabilities, etc. for a user terminal. Typically, the session is long-term. The connection is a radio data path that is typically established according to the communication needs and thereafter closed. Typically, the connection is short-lived.

[0026] For the non-hierarchical architecture shown in fig. 1, user terminal 110 has previously established a session (which may be via any access point in the system), and access point 120a currently maintains the session for user terminal 110. For a hierarchical architecture, the central network entity maintains a session for the user terminal, and the access point 120a knows the content of the session. For clarity, the following description is for a non-hierarchical architecture. User terminal 110 is mobile and has moved from the coverage of access point 120a to within the coverage of access points 120b and 120 c. Access point 120a is located within geographic area 102 and access points 120b and 120c are located within different geographic areas 104. To communicate, user terminal 110 may attempt to establish a connection with access points 120b and/or 120 c.

[0027] For clarity, the following terms are used in the following description. A session holding access point is an access point that holds sessions for user terminals, and may or may not be the access point with which the user terminal initially established a session, since the session may be transferred from one access point to another. A "target" access point is an access point with which a terminal attempts to establish a connection. An "anchor" access point is an access point that manages the connection and active set of user terminals. A "serving" access point is an access point that is currently serving a connection for a user terminal. Typically, after the connection setup is completed, the target access point becomes the serving and anchor access point for the user terminal.

[0028] Backbone 130a interconnects access points 120a, a Universal Access Terminal Identifier (UATI) lookup server 140, and a Home Agent (HA)142 within geographic area 102. The UATI is a unique identifier assigned to each user terminal for uniquely identifying the user terminal. The UATI lookup server 140 stores a list of user terminals that have had sessions in the system (e.g., marked by their UATIs). The UATI lookup server 140 may be accessed to determine the session maintenance access point for any user terminal in the system (which for the example of fig. 1 consists of geographic areas 102 and 104). The home agent 142 provides a data connection for the user terminal using the session that is being conducted in the system (consisting of the geographic regions 102 and 104).

[0029] Backbone 130b interconnects access points 120b and 120c and local service server 150. The local service server 150 may provide services such as 911 emergency services, network access, push-to-talk (PTT), voice over internet protocol (VoIP), and the like. The techniques described herein allow for quick and reliable access to the local service server 150 regardless of the state of the backbone 130 b. This quick and reliable access is particularly important for 911 and other emergency services.

[0030] Fig. 2 shows an exemplary air interface protocol stack 200 that may be used for radio communications between user terminal 110 and any access point 120. The protocol stack 200 is different from the Open Systems Interconnection (OSI) protocol stack. For the embodiment shown in fig. 2, the protocol stack 200 includes 7 layers: a physical layer 210, a Media Access Control (MAC) layer 212, a security layer 214, a connection layer 216, a session layer 218, a stream layer 220, and an application layer 222.

[0031] The physical layer 210 defines the physical characteristics of the transmission between the user terminal and the access point. These physical characteristics may include, for example, channel structure, transmission frequency, output transmit power level, coding scheme, modulation format, etc. for the forward and reverse links. The MAC layer 212 defines procedures for transmitting, receiving, and processing data on the physical layer 210. The security layer 214 provides protected services such as authentication and encryption services. The connectivity layer 216 provides radio connection establishment and maintenance services. The session layer 218 provides layer and protocol negotiation, protocol configuration, and state maintenance services. Stream layer 220 provides multiplexing of various application streams. The application layer 222 supports applications such as signaling applications that send air interface protocol messages, packet data applications that send user traffic data, Radio Link Protocols (RLPs) that provide data retransmission capabilities for improved reliability, and the like. The protocol stack 200 may be implemented in various ways. An exemplary implementation of the protocol stack 200 is described in version 2.0 of 3gpp2c.s0024 entitled "cdma 2000 High Rate Packet Data Air Interface Specification" at day 27, month 10, 2000.

[0032] Typically, a session includes many parameters for the various protocols within the protocol stack 200. The session may also include additional configuration parameters that are not part of the protocol stack 200. In general, the layers described above for protocol stack 200 are relevant for air interface compatibility between a user terminal and an access point.

[0033] Each layer in the protocol stack 200 utilizes various protocols to implement the designed functionality. For example, the MAC layer may utilize a hybrid automatic repeat request (HARQ) protocol in order to incrementally transmit each data packet. The security layer may utilize separate encryption and authentication protocols. The connection layer may utilize an active set protocol to manage the set of access points with which the user terminal may communicate. There may be multiple versions or subtypes of a given protocol. Each protocol may also have various configurable parameters. Protocols within the same layer as well as protocols within different layers may be configured independently. The user terminal may communicate with the access point using only a subset of all protocols for these seven layers. Protocols for communication typically need to be synchronized at the user terminal and the access point. Each protocol performs peer-to-peer communication. Some protocols can communicate only if the protocol states are synchronized such that both the user terminal and the access point use the same protocol version and configurable parameter values. Other protocols may communicate with parameter values that are not the same at the transmitter and receiver, although typically they have some degradation in performance. For example, a protocol at the transmitter may consider that RLP NAK is not enabled, while a peer-to-peer protocol at the receiver may consider that RLP NAK is enabled, in which case the transmitter will not send a NAK and quality of service may degrade.

[0034] The session information for a given user terminal includes all relevant information for the protocol and parameter values used for communication. The session information may be divided into a plurality of classes or components. In an embodiment, the session information is divided into two categories referred to as user-specific session information and modem configuration information.

[0035] The user-specific session information may include the following:

1. security keys-used by the security layer for encryption and authentication;

RLP flow parameters — determining whether to send a Negative Acknowledgement (NAK) for each RLP flow, along with other attributes of the RLP;

3. quality of service (QoS) information — determining multiplexing and transport of data, e.g., mapping of Internet Protocol (IP) ports to RLP flows, which are data flows at the RLP;

4. token bucket adjuster state-for fairness considerations;

5. addressing information-UATI or some other address for the user terminal;

6. paging cycle and offset-indicating when a paging message may be sent to a user terminal.

[0036] The modem configuration information may include the following:

1. protocol versions of all protocols used for radio communication;

2. pilot increase/decrease threshold-determining a pilot strength level at which new access points should be added or current access points should be decreased from a candidate set maintained by the user terminal;

3. access class-determining the priority of a user terminal when making an access attempt;

4. control channel signaling scheme — determining a bit specification (e.g., power control bits, channel quality report bits) to send on a control channel;

5. other non-user specific air interface information.

[0037] The above are examples of some types of information for user-specific session information and modem configuration information. These examples are given for illustrative purposes. Typically, the user-specific session information comprises information that is not necessary for establishing a stable radio connection, and the modem configuration information comprises information relating to radio communication. Typically, the type of information to be included in each class depends on the network design.

[0038] In general, session information may be divided into any number of classes, and each class may cover any type of information. A given configurable parameter may appear in multiple classes. For example, the modem configuration information may comprise default values for a parameter (which may be suitable for radio communication but may be sub-optimal), and the user-specific session information may comprise another (better) value for the same parameter. The session information will then include two parameter values, which can be classified into different classes. For simplicity, most of the description below assumes the use of both of the classes described above.

[0039] The modem configuration information has the following features. First, the modem configuration information at the user terminal and the network is the same for a given session. If the user terminal and the network use different values for any of the parameters, the behavior may be unpredictable. Second, the network allows only certain combinations of modem configuration information. Third, the modem-specific configuration information itself is sufficient to enable basic communication between the user terminal and the access point, and such communication may be important for fast and reliable communication with the local service server 150.

[0040] A limited number of modem-specific configurations can be defined and made available in the network. Each modem-specific configuration is associated with specific modem configuration information that indicates (1) the protocol versions for the layers of the protocol stack and (2) the parameter values for these protocol versions. The number of allowed modem-specific configurations may be a small subset of all possible modem-specific configurations. The number of modem-specific configurations allowed is large enough to provide flexibility in serving a wide range of user terminals, but small enough for ease of maintenance. Different modem-specific configurations may be used for different user terminals based on their hardware type, service protocols, etc.

[0041] Each allowed modem-specific configuration may be assigned a different token that uniquely identifies the modem-specific configuration. The token is an N-bit value that represents a particular modem-specific configuration, where N is determined by the number of modem-specific configurations supported by the network. Table 1 lists class 4 modem specific configurations, exemplary token value ranges for class 4 16-bit tokens, and a short description thereof. In table 1, 0x — represents a 16-ary value defined by 4 16-ary numbers following 'x'.

TABLE 1

Modem specific configuration	Token value	Definition of
			By default	0x0000	Default modem specific configuration with default version and parameters for all relevant protocols
Standard of merit	0x0001-0x0FFF	Modem specific configuration specified in air interface specification
			Pre-configuration	0x1000-0x7FFF	Modem-specific configuration pre-configured by the network and specified during session establishment
Non-preconfigured	0x8000-0xFFFF	Modem-specific configuration that is not preconfigured

[0042] Default modem-specific configuration refers to an air interface protocol stack that uses default versions and default parameter values for all protocols. Standard modem-specific configuration means that the protocol version and parameter values are the air interface protocol stack specified in the air interface specification. Each of the proprietary compliant access points supports standard modem-specific configurations. Pre-configured modem-specific configuration refers to the protocol version and parameter values being the air interface protocol stack specified for the network (e.g., by the network operator). All access points within the network are aware of the pre-configured modem specific configuration and their associated tokens. Non-pre-configured modem-specific configuration refers to an air interface protocol stack that may not be recognized across the entire network. Different regions of the network may define different sets of non-preconfigured modem specific configurations. The access points within each area will identify the portion of the allowed non-pre-configured modem specific configuration set.

[0043] Fig. 3A illustrates the division of session information for user terminal 110 into user-specific session information and modem configuration information. The modem configuration information is associated with a unique token that conveniently and efficiently conveys this information with a single N-bit value.

[0044] As described above, the session information may also be divided into more than two classes, and each class may be associated with a different set of tokens. For each class, each session information combination allowed for the class is assigned a different token (from the set of tokens for the class), which uniquely communicates the session information combination. The ranges of token values given in table 1 represent particular embodiments, and other token value ranges may also be used for each class.

[0045] Fig. 3B shows a protocol stack for a connection. The modem-specific protocol stack may be constructed with modem configuration information for the session and may be used to provide the radio connection. A "complete" protocol stack may be obtained by updating the modem specific protocol stack with user specific session information. As described below, the modem specific protocol and the complete protocol stack provide different capabilities.

[0046] Referring back to fig. 1, each access point 120 in network 100 may maintain a token table (as shown in fig. 1), or may access the token table. The token table may include an entry for each allowed token, and each entry may contain all modem configuration information related to that token. Each access point 120 may use the token table to obtain modem configuration information for any allowed tokens.

[0047] Fig. 4 shows a process 400 for establishing a connection using a token. User terminal 110 initially establishes a session with access point 120a and obtains at least one token, where each token is associated with particular modem configuration information for the user terminal (block 410). For example, a user terminal may obtain multiple tokens for different types of applications (e.g., a token for making an emergency call, a token for obtaining a data connection, etc.). As another example, the user terminal may obtain multiple tokens for different protocol versions (e.g., a token for a current version, a token for a previous version, etc.). The token may be associated with parameters that are just needed for sending signaling (e.g., for an emergency call). The token may also be associated with additional parameters that allow data exchange.

[0048] The user terminal then attempts to establish a connection with the target access point 120b by sending a connection request message containing an identifier of the user terminal and a token for the relevant modem configuration information (block 412). A message may also be referred to as a packet, or some other terminology. The user terminal identifier may be a UATI assigned to the user terminal, an Access Terminal Identifier (ATI) containing the 32 least significant bits of the UATI, or some other type of identifier for the user terminal. The identifier may also be omitted from the connection request message and sent by the user terminal after granting access. The connection request message may also indicate that the user terminal does not want to have a session with the target access point.

[0049] The target access point receives the connection request message from the user terminal, extracts the token from the message, and obtains modem configuration information (e.g., using a token table) associated with the token (block 414). The target access point initializes the air interface protocol stack with the modem configuration information associated with the token and obtains a modem-specific protocol stack for the user terminal (block 416). The target access point then sends a connection response message back to the user terminal to indicate successful connection establishment (block 418). The user terminal receives the connection response message (block 420). The user terminal and the target access point then communicate in accordance with the modem-specific protocol stack for the user terminal (blocks 422 and 424).

[0050] Fig. 4 illustrates a scenario in which a user terminal sends a valid token and the target access point is not a session maintenance access point for the user terminal. The connection establishment may proceed in different ways depending on the information available at the target access point.

[0051] Fig. 5 shows a process 500 performed by the target access point 120b for communicating with the user terminal 110. The target access point receives the UATI and the token from the user terminal (block 510). The target access point determines whether the session (marked by the UATI) for the user terminal is stored/cached by the access point (block 512). If the answer to block 512 is yes, the target access point resumes the session for the user terminal (block 514) and initializes the air interface protocol stack with the session information to obtain a complete protocol stack for the user terminal (block 516). The target access point then sends a connection response message indicating that a session was found (block 518). The target access point may then communicate with the user terminal using the full protocol stack, for example, for protected or unprotected data exchange (block 520).

[0052] If the target access point does not have a cached session for the user terminal and the answer to block 512 is no, then the target access point determines whether the token received from the user terminal is valid (block 522). A valid token is a token that is identified and supported by the receiving access point. A token that is allowed by the network but for any reason is not recognized or supported by the receiving access point will be considered an invalid token by that access point. If the answer to block 522 is yes, the target access point obtains modem configuration information associated with the token (block 524) and initializes an air interface protocol stack with the modem configuration information to obtain a modem specific protocol stack for the user terminal (block 526). The target access point then sends a connection response message indicating that the token was identified (block 528). The target access point may then communicate with the user terminal using the modem-specific protocol stack (block 530). Data may be exchanged between the target access point and the user terminal without security or with security provided by higher layers located above the radio link protocol stack (block 530).

[0053] The system may support two or more types of security. A security layer in the air interface protocol stack provides over-the-air security. Higher layers may provide end-to-end security. Both layers can exchange data. For example, user terminals may exchange unencrypted signaling and encrypted data. The target access point may terminate unencrypted signaling and may forward encrypted data (as well as encrypted signaling) to the session-holding access point. The user terminal may also send data encrypted at higher layers without additional over-the-air encryption and may forward the encrypted data to the target access point or may use it for local services.

[0054] The target access point attempts to locate and retrieve the session for the user terminal, such as via the UATI lookup server 140 and the session holding access point 120a (block 532). If a session is found and retrieved as determined in block 534, the target access point updates the modem-specific protocol stack with the user-specific session information to obtain a complete protocol stack for the user terminal (block 536). The target access point then sends another connection response message indicating that a session was found (block 518). The target access point may then communicate with the user terminal using the full protocol stack (block 520). Otherwise, if a session is not found, as determined in block 534, the target access point may continue to communicate with the user terminal using the modem-specific protocol stack (block 538). Alternatively, the target access point may instruct the user terminal to create a new session, since the access point may need to access the session to allow the data service. Retrieval sessions may take a variable amount of time. Typically, since the target access point does not know whether a session for the user terminal exists, the target access point may set a timer to a predetermined value when initiating a retrieval session, and when the timer expires, the target access point may assume that no session was found.

[0055] The token received from the user terminal may not be valid for various reasons. For example, the token may be (1) a token that is not allowed by the system, (2) a token that is not recognized by the target access point, or (3) a token that is recognized by the target access point but is not supported (e.g., a token for a new protocol version that is not supported by the access point). If, for any reason, the token is not valid and the answer to block 522 is no, the target access point may send a connection response message indicating that the token was not recognized (or recognized but not supported) by the target access point (not shown in fig. 5). The message may cause the user terminal to send another token. The target access point determines whether to locate and retrieve a session for the user terminal (block 542). The decision may be made based on various factors such as UATI, token received from the user terminal, etc. For example, a UATI or token may indicate that the user terminal belongs to another network operator or is currently roaming. A parameter for the operator ID may be defined (e.g. in the token, as described below) and may be used to indicate which network operator stores the session for the user terminal. If the session is to be retrieved and the answer to block 542 is yes, then the target access point sends a connection response message indicating that the session is being retrieved and the token is not recognized (block 544). The target access point then attempts to retrieve the session for the user terminal from the session holding access point (block 546). No communication occurs between the target access point and the user terminal while the session is being retrieved. A determination is then made whether a session is found (block 548). If no session is found (e.g., timer expires) and the answer to block 548 is no, the target access point may send a connection close message to the user terminal indicating that no session was found (block 550). The target access point may also send a connection close message for the invalid token after block 522. The connection close message forces the user terminal to establish a new session with the target access point.

[0056] If the target access point decides not to retrieve the session for the user terminal and the answer to block 542 is no, then the target access point sends a connection response message indicating that the token is invalid and that there is no session (block 552). The connection response message may cause the user terminal to attempt to establish a connection with another token or to establish a new session with the target access point.

[0057] Fig. 6 shows a process 600 performed by the user terminal 110 to communicate with the target access point 120 b. The user terminal sends a connection request message with the UATI and token to the target access point to attempt to establish a connection (block 610). The user terminal then waits for a connection response message or some other message from the target access point. If a connection response message is received, as determined in block 612, the user terminal checks the contents of the message to determine the status of the connection.

[0058] If the connection response message indicates that a session is found for the user terminal, as determined in block 614, the user terminal communicates with the target access point using the full protocol stack (block 616). If a session is not found but the token is identified by the target access point, as determined in block 618, the user terminal communicates with the target access point using the modem-specific protocol stack (block 620). The user terminal may also communicate with the target access point using the full protocol stack. The target access point may then store data that may not be processed without the complete protocol stack and may either (1) process the data after retrieving the session for the user terminal or (2) forward the data to the session holding access point. If the token is not recognized and the session is being retrieved, as determined in block 622, the user terminal waits for another connection response message indicating the result of the retrieval (block 624). If another connection response message is not received within the predetermined time period, the user terminal may send another connection request message with the UATI and the same token. If the token is not recognized and the session is not retrieved, as determined in block 626, the user terminal may send another connection request message with the UATI and another token (block 628). The user terminal returns from blocks 620, 624 and 628 to block 612 and remains alert for another message from the target access point.

[0059] The user terminal may receive a message other than the connection response message in response to the connection request message. For example, the user terminal may receive a resource allocation message that allocates resources on the forward link and/or reverse link for the user terminal (block 630). In this case, the user terminal assumes that it has received a connection response message from the target access point. The user terminal then communicates with the target access point using (1) the recently configured protocol stack if the user terminal has previously communicated with the access point, or (2) the modem-specific protocol stack if the user terminal has not previously communicated with the access point (block 632). The use of resource allocation messages is useful for rapid transitions between active and sleep states and avoids intermediate signaling for connection response messages. In general, any message that is not sent until a session is found may be used to indicate that a session is found for the user terminal.

[0060] If the user terminal receives a connection close message, as determined in block 634, the user terminal may attempt to establish a new session with the target access point (block 636). The process terminates after blocks 616, 632, and 636.

[0061] Fig. 5 and 6 illustrate particular embodiments of processing by the target access point and the user terminal for communication. The processing by the target access point and the user terminal may also be performed in many other ways. Typically, the processing by the user terminal is complementary to the processing by the target access point.

[0062] Fig. 7A and 7B illustrate a call flow 700 for establishing a connection for a user terminal 110(UT) via a target access point 120B (AP1) when a session for the user terminal is not cached at the target access point. In fig. 7A, the user terminal generates a connection request message with a UATI and a token (step 710). The user terminal may also generate a pilot report message containing pilot strength measurements for all access points received by the user terminal with sufficient strength. In this example, the pilot report instructs the user terminal to receive access point 120b (AP1) and access point 120c (AP2) with sufficient strength. The user terminal sends a connection request message and a pilot report message to the AP1 (step 712). The connection request message requests a radio data path for the user terminal.

[0063] The AP1 receives the connection request message from the user terminal, extracts the UATI, and determines that it does not cache session information for the user terminal (step 714). The AP1 also receives the pilot report message, determines that AP2 is included in the pilot report, and sends an Active Set (ASET) addition request message to AP2 to ask if AP2 can be added to the active set of the user terminal (step 716). AP1 also forwards the connection request message to UATI lookup server 140 using the address of UATI lookup server 140, which is preconfigured at AP1 (step 718). The AP1 initializes the air interface protocol stack with the modem configuration information associated with the token sent in the connection request message (block 720). Subsequently, the AP1 sends a connection response message to the user terminal indicating that the token was identified and that the session is being retrieved (step 722).

[0064] The AP2 receives the ASET addition request message from the AP1, allocates resources to the user terminal (step 724), and sends an ASET addition response message back to the AP1 (step 726). The AP1 receives the ASET addition response message, determines that AP2 has allocated resources for the user terminal, and sends an active set allocation message containing AP1 and AP2 to the user terminal (step 728). The user terminal receives the active set assignment message and uses the assigned active set with AP1 and AP2 (step 730).

[0065] In fig. 7B, the UATI lookup server 140 receives the connection request message from the AP1, extracts the UATI for the user terminal, determines a session maintenance access point (AP0) for the user terminal based on the UATI, and forwards the connection request message to the AP0 (step 732). Subsequently, AP0 and AP1 perform security and authentication based on procedures specified by the network, if necessary (step 734). Once the process is complete, the AP0 sends a session information message to the AP1 containing session information for the user terminal (e.g., security keys and protocols previously negotiated between the user terminal and the AP0) (step 736). The AP1 receives the session information message from the AP0 and extracts user-specific session information. Subsequently, the AP1 sends the security key to the AP2 in the active set (step 738), and the AP2 responds with a reply (step 740). AP1 and AP2 then update the modem specific protocol stack with the user specific protocol stack to obtain the complete protocol stack for the user terminal (step 742).

[0066] The AP1 then sends another connection response message to the user terminal indicating that a session was found (step 744). The user terminal may then use the security keys available to the complete protocol stack (step 746). Thereafter, the user terminal and the AP1 may exchange protected or unprotected data on the traffic channel (step 748). During the time period from block 710 to block 746, the user terminal may send messages for radio link stability (or other related functions) that are not encrypted so that AP1 may receive and process the messages. For example, the handoff of the user terminal from AP1 to AP2 may occur without session information at AP1 and AP2, if desired. As described above, during the time period from block 710 to block 746, the user terminal may use security and send protected data. During this time period, the AP1 may store or forward the protected data and can decrypt the protected data after block 742.

[0067] Fig. 7A and 7B illustrate a specific call flow for establishing a connection for a user terminal. The signaling may also be sent in other ways than shown in fig. 7A and 7B. For example, the AP0 may communicate simultaneously with the AP1 and the AP2 and may provide sessions directly to the AP1 and the AP 2.

[0068] Fig. 8 shows a diagram of communications between the user terminal 110 and the access points 120a (AP0), 120b (AP1), and 120c (AP 2). The AP0 maintains the session for the user terminal but typically does not control the connection. The control over the connection may be distributed. For some networks, the AP0 may control the connection, e.g., only certain messages such as a close connection, exchange to another mode, etc. messages may be initiated from the AP 0. The AP0 also functions as a mobile IP node for the user terminal and as a proxy for a mobile or permanent IP address assigned to the user terminal. The AP0 receives incoming packets sent by other hosts and servers to the user terminal IP address and forwards these packets to the user terminal. The AP0 also receives outgoing packets from the user terminal and sends these packets to the receiving host with the IP address of the user terminal as the source address. The home agent 142 provides a data connection for packet switching with foreign hosts and servers. The user terminal and AP0 communicate using the complete protocol stack for the user terminal.

[0069] The AP1 controls the connections for the user terminal (e.g., manages the active set) and is the anchor access point for the connections. The AP2 is a member of the active set and is the current serving access point for the user terminal. The user terminal may communicate with AP1 and/or AP2 at any given moment and may quickly switch between the two access points. AP1 and AP2 communicate with the user terminal using a modem-specific protocol stack for the user terminal.

[0070] As shown in fig. 8, the user terminal may obtain local services via the AP 1. For example, the user terminal may transmit packets to the local service server 150 via the AP1 using simple IP, e.g., the local service server 150 may be an internet server, a push-to-talk server, an emergency 911 server, a media billing server, etc. The local service may be an unprotected service or may use higher layer protection (e.g., IPSec or some other protocol). AP1 may provide local services even if sessions for user terminals have not been retrieved or transferred from AP 0.

[0071] Fig. 9 shows the air interface protocol stack for communication between a user terminal and an anchor access point (AP1) and a session maintenance access point (AP0), in this case AP1 identifies a token sent by the user terminal but does not have a session. Fig. 9 shows the termination points for each layer for a particular embodiment, and solid arrows are used in fig. 8. In general, peer-to-peer communication for each layer depends on various factors such as protocol design and configuration. A given function may be accomplished through AP0 and AP1, and a given layer may terminate at two access points. In any event, at the MAC and physical layers, the modem-specific protocol stack is sufficient to give the AP1 all relevant information needed to communicate with the user terminal. In this way, the MAC layer and the physical layer may operate in the same manner as if the AP1 had a session for the user terminal.

[0072] At the security layer, the AP1 does not have a security key and therefore cannot decrypt the packet or detect the authentication header. Until the AP1 obtains the security key, the user terminal and the AP1 cannot use the security protocol. If the user terminal sends packets with security enabled, the packets may be buffered at AP1 until the session is retrieved or immediately forwarded to AP 0. Security may be enabled based on the security bits in each packet or may be indicated by a token. These packets may use authentication by adding an explicit authentication header that is detected at the AP 1. All signaling messages between the user terminal and the AP1 are sent with no security enabled.

[0073] The session, stream and application layers are at AP 0. AP1 forwards all but signaling and local service flows to AP 0. At the application layer, the signaling application runs at the AP1 and its parameters are specified by the token.

[0074] The connection request message sent by the user terminal to the target access point may convey various types of information useful for establishing a connection. The message may have various formats. Table 2 shows an exemplary format for the connection request message.

TABLE 2 connection request message

Field(s)	Size (bit)	Definition of
			Address_Included	1	Indicating whether an address is included in a message
Address_Type	2	'00' -indicates that a full 128-bit UATI is being sent

		'01' -indicates that a short 32-bit ATI '10' -reserved value '11' -is being sent indicating a new session or no address available
			Address_Record	0, 32 or 128	If the Address _ Type is '00' or '01', respectively, 128 bits UATI or '01' is carried for the user terminal32 bit ATI
Token_Included	1	Indicating whether a token is included in a message
			Token	16	16-bit token carrying modem configuration information for user terminals

[0075] Typically, the connection request message includes the UATI when the user terminal is establishing a connection with the target access point. The connection request message may include ATI if there is no ambiguity in the address for the user terminal. This may be the case, for example, if the user terminal has previously established a connection with the target access point and is now transitioning between an idle state and a connected state for communicating with the same access point. The connection request message may also omit the token if there is no ambiguity (e.g., for the fast transfer described above). When no token is provided in the connection request message, the target access point may assume that the token for the previous connection attempt is being used again.

[0076] Table 2 indicates that modem configuration information for a user terminal can be efficiently transmitted using a single token. The connection request message may have fewer, more, and/or different fields. For example, the connection request message may include a 1-bit field indicating whether additional fields are included in the message. The extra field may carry other session information (e.g., security keys) that is not passed by the token.

[0077] For example, for a MAC Protocol Data Unit (PDU) sent by the user terminal to the target access point, the connection request message may be sent in a MAC header. The connection request message may be a message included in a packet containing other messages or data such as the pilot report message described above with respect to fig. 7A. The connection request message is defined by all protocol versions supported by the network and can be recognized by all access points in the network.

[0078] The connection response message sent by the target access point to the user terminal may convey various types of information that may be useful for determining the status of the connection. The message may also have various formats. Table 3 shows an exemplary format for the connection response message.

TABLE 3 connection response message

Field(s)	Size (bit)	Definition of
			MAC ID	8	Carrying a MAC identifier (MAC ID) assigned to a user terminal for use during a connection in order to identify the user terminal
Token_Recognized	1	'0' -indicating that a token transmitted by a user terminal is recognized by an access point, '1' -indicating that the token is not recognized
			Session_Found	1	'0' -indicating that a session for the user terminal is found '1' -indicating that no session is found
Wait_for_Session	1	'0' -indicating that a session is being retrieved, '1' -indicating that a session is not being retrieved or is unavailable

[0079] The connection response message may have fewer, more, and/or different fields. For example, the connection response message may include a 1-bit field indicating whether additional fields are included in the message. The extra field may carry information such as a request for some user-specific session information that is not passed by the token (e.g., security keys, paging information, etc.).

[0080] As shown in fig. 6 and 7, the target access point may send one or more connection response messages to the user terminal for connection establishment. The Token _ corrected, Session _ Found, and Wait _ for _ Session bits in each connection response message are set based on information available at the target access point for the user terminal.

[0081] In the description above and illustrated in table 1, the token conveys all modem configuration information in a single token value. The token may also be defined in a number of fields. Each field may be considered a subtoken, and each subtoken may convey some information useful for communication. For example, each sub-token may convey (1) parameter values for different layers, (2) information for a set of protocols, or (3) other relevant information (e.g., network operator ID).

[0082] The sub-token may be used in various ways. For example, a set of protocols at all layers for system access may be described by the first N bits of the token, and the remaining protocols may be described by the remaining bits of the token. In this way, access may be allowed but no data service.

[0083] Fig. 10 shows a block diagram of a user terminal 110 and an access point 120x, which access point 120x may be any access point within the network 100 of fig. 1. For the reverse link, at user terminal 110, a Transmit (TX) data processor 1010 receives traffic data from a data source 1008 and signaling (e.g., a connection request message) from a controller 1030, processes (e.g., formats, codes, interleaves, and modulates) the traffic data and signaling, and generates modulation symbols. A transmitter unit (TMTR)1012 performs processing specified by the network and generates data chips. For example, transmitter unit 1012 may perform OFDM modulation for an OFDMA system, transmitter unit 1012 may perform spreading for a CDMA system, and so on. Transmitter unit 1012 further conditions (e.g., converts to analog, filters, amplifies, and frequency upconverts) the data chips to generate a modulated signal, which is transmitted from an antenna 1014.

[0084] At access point 120x, the modulated signal transmitted by user terminal 110 is received by antenna 1052. A receiver unit (RCVR)1054 processes (e.g., conditions and digitizes) the received signal from antenna 1052, performs processing complementary to that performed by transmitter unit 1012, and provides received symbols. A Receive (RX) data processor 1056 processes (e.g., demodulates, deinterleaves, and decodes) the received symbols, provides decoded traffic data for user terminal 110 to a data sink 1058, and provides received signaling to a controller 1070.

[0085] For the forward link, at access point 120x, a TX data processor 1062 receives traffic data for user terminal 110 and other user terminals from a data source 1060 and signaling (e.g., a connection response message) from a controller 1070. A TX data processor 1062 processes traffic data and signaling and generates modulation symbols. A transmitter unit 1064 processes the modulation symbols, performs signal conditioning, and provides a modulated signal, which is transmitted from an antenna 1052. At user terminal 110, the modulated signals transmitted by access point 120x and other access points are received by an antenna 1014, conditioned and digitized by a receiver unit 1020, and processed by an RX data processor 1022. An RX data processor 1022 provides decoded traffic data for user terminal 110 to a data sink 1024 and provides recovered signaling for user terminal 110 to a controller 1030.

[0086] Controllers 1030 and 1070 control the operation at user terminal 110 and access point 120x, respectively. Memory units 1032 and 1072 store program codes and data used by controllers 1030 and 1070, respectively. Memory unit 1032 may also store session information and tokens for user terminal 110. Memory unit 1072 may also store session information or modem configuration information, token tables, etc. for user terminal 110. Controller 1030 establishes and manages connections and sessions for user terminal 110 and may implement portions of process 400 in fig. 4, process 600 in fig. 6, and process 700 in fig. 7A and 7B. Controller 1070 manages connections and possible sessions for user terminal 110 and may implement process 400 in fig. 4, process 500 in fig. 5, and portions of process 700 in fig. 7A and 7B.

[0087] The connection establishment techniques described herein achieve the following goals:

1. radio link stability: during the time the network locates a session for the user terminal, a stable radio connection between the user terminal and the network may be established. Handover between access points may also be effected for a user terminal before a session for the user terminal is found.

2. Local service provision: in the absence of a session or even in the absence of a session, the anchor access point may provide local services for the user terminal.

3. Data service: the user terminal may send protected or unprotected data to the session holding access point before finding the session or if the session is not transferred to the anchor access point.

[0088] The connection establishment techniques also provide other benefits and advantages. First, the technique provides flexibility for connection establishment. The network operator may determine which protocol version and combination of parameter values are useful, classify the combinations as pre-configured modem-specific configurations, and assign tokens to the configurations. The network operator can easily define new modem-specific configurations and update the token table. The access point can easily obtain the token table via the backbone network. Second, the technique allows for efficient connection establishment. The pre-configured modem specific configuration and its assigned token may be communicated to the user terminal at the start of the session. The subscriber terminal may use the modem-specific configuration for extended periods of time (e.g., days). To communicate with an access point, the user terminal may only send a token to the new target access point in order to establish a connection. This connection setup is fast since (1) the user terminal does not need to send a lengthy list of parameter values to the target access point and (2) the target access point does not need to retrieve the session for the user terminal from the session holding access point.

[0089] The connection establishment techniques described herein may be used for various wireless and wireline multiple-access communication systems. For example, the techniques may be used for Orthogonal Frequency Division Multiple Access (OFDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Code Division Multiple Access (CDMA) systems, and the like.

[0090] The connection establishment techniques described herein may be implemented in various ways. For example, these techniques may be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units used for connection establishment at the user terminal (e.g., each of the processing units shown in fig. 10, or a combination of processing units) may be implemented within one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or a combination thereof. The processing unit for connection establishment at the access point may also be implemented in one or more ASICs, DSPs, processors, electronics, and so on.

[0091] For a software implementation, the connection establishment techniques may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit (e.g., memory unit 1032 or 1072 in fig. 10) and executed by a processor (e.g., controller 1030 or 1070). The memory unit may be implemented within the processor or external to the processor.

[0092] The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (35)

1. An apparatus in a communication network, comprising:

a controller that receives a first message transmitted by a user terminal to establish a connection, extracts a token included in the first message, obtains modem configuration information related to the token, and transmits a second message to the user terminal, the second message indicating successful connection establishment based on the token; and

at least one data processor exchanging data with the user terminal according to the modem configuration information.

2. The apparatus of claim 1, wherein the controller constructs a protocol stack for the user terminal with the modem configuration information, and wherein the at least one data processor exchanges data with the user terminal according to the protocol stack.

3. The apparatus of claim 1, further comprising:

a memory unit storing a token table including tokens allowed by the network.

4. The apparatus of claim 1, wherein the controller further determines whether the token is valid, and if the token is valid, the controller obtains the modem configuration information and sends the second message.

5. The apparatus of claim 4, wherein the controller looks up the token in a token table containing tokens allowed by the network and indicates that the token is valid if the token is found in the token table.

6. The apparatus of claim 1, wherein the controller determines whether a session for the user terminal is available in local memory, and wherein the at least one data processor exchanges data with the user terminal according to the session for the user terminal if the session is available.

7. The apparatus of claim 1, wherein the controller initiates retrieval of a session for the user terminal from the network, and wherein the at least one data processor exchanges data with the user terminal according to the session for the user terminal if the session is retrieved.

8. The apparatus of claim 1, wherein the at least one data processor receives packets for mobile Internet Protocol (IP) from the user terminal and forwards the packets for mobile IP to the network.

9. The apparatus of claim 1, wherein the at least one data processor receives a packet for simple Internet Protocol (IP) from the user terminal, and terminates the packet for simple IP received from the user terminal.

10. The apparatus of claim 7, wherein the session for the user terminal comprises the modem configuration information and user-specific session information for the user terminal.

11. The apparatus of claim 10, wherein the user-specific session information comprises a security key, and wherein the at least one data processor securely exchanges data using the security key if the session is retrieved.

12. The apparatus of claim 1, wherein the token comprises a plurality of fields, and wherein each field is associated with a respective protocol or set of information available for communication.

13. A method of communicating in a communication network, comprising:

receiving a first message sent by a user terminal to establish a connection;

obtaining a token from the first message, the token indicating modem configuration information to be used for the connection;

obtaining the modem configuration information related to the token;

sending a second message to the user terminal, the second message indicating successful connection establishment based on the token; and

and exchanging data with the user terminal according to the modem configuration information.

14. The method of claim 13, further comprising:

determining whether the token is valid; and

performing said obtaining said modem configuration information, sending said second message to said user terminal, and exchanging data with said user terminal if said token is valid.

15. The method of claim 14, further comprising:

if the token is not valid and a session for the user terminal is not found, a message is sent to the user terminal indicating that the connection is closed.

16. The method of claim 14, further comprising:

if the token is identified but not supported, a message is sent to the user terminal indicating that the token is identified but not supported.

17. The method of claim 13, further comprising:

determining whether a session for the user terminal is available in local memory; and

exchanging data with the user terminal according to the session for the user terminal if the session is available.

18. The method of claim 13, further comprising:

retrieving a session for the user terminal from the network; and

if the session is retrieved, data is exchanged with the user terminal according to the session for the user terminal.

19. An apparatus in a communication network, comprising:

means for receiving a first message sent by a user terminal to establish a connection;

means for obtaining a token from the first message, the token indicating modem configuration information to be used for the connection;

means for obtaining the modem configuration information associated with the token;

means for sending a second message to the user terminal, the second message indicating a successful connection establishment based on the token; and

means for exchanging data with the user terminal based on the modem configuration information.

20. The apparatus of claim 19, further comprising:

means for determining whether the token is valid; and

means for enabling the means for obtaining the modem configuration information, the means for sending the second message, and the means for exchanging data with the user terminal if the token is valid.

21. The apparatus of claim 19, further comprising:

means for determining whether a session for the user terminal is available in local memory; and

means for exchanging data with the user terminal according to the session for the user terminal if the session is available.

22. The apparatus of claim 19, further comprising:

means for retrieving a session for the user terminal from the network; and

means for exchanging data with the user terminal in accordance with the session for the user terminal if the session is retrieved from the network.

23. An apparatus in a communication network, comprising:

a controller that sends first information to a first access point to establish a connection and receives a second message from the first access point indicating a successful connection establishment, wherein the first message contains a token indicating modem configuration information to be used for the connection, and wherein the connection establishment is based on the token; and

at least one data processor that exchanges data with the first access point according to the modem configuration information.

24. The apparatus of claim 23, wherein the controller selects the token from a plurality of tokens available to the apparatus, each of the plurality of tokens associated with dedicated modem configuration information.

25. The apparatus of claim 23, wherein the controller is further to establish a session with a second access point and obtain the token related to the modem configuration information from the second access point, wherein the session comprises the modem configuration information and user-specific session information.

26. The apparatus of claim 23, wherein the at least one data processor exchanges data with a second access point based on a previously established session for the user terminal.

27. The apparatus of claim 26, wherein the at least one data processor exchanges data with the first access point using simple Internet Protocol (IP) and exchanges data with the second access point using mobile IP.

28. The apparatus of claim 26, wherein the at least one data processor receives local data services via the first access point and global data services via the second access point.

29. The apparatus of claim 23, wherein the controller is to receive a third message from the first access point indicating that a session for the user terminal has been retrieved, and wherein the at least one data processor is to exchange data with the first access point according to the session.

30. A method of communicating in a communication network, comprising:

sending a first message from a user terminal to a first access point to establish a connection, the first message including a token indicating modem configuration information to be used for the connection;

receiving a second message from the first access point, the second message indicating a successful connection establishment based on the token; and

exchanging data with the first access point according to the modem configuration information.

31. The method of claim 30, further comprising:

establishing a session with a second access point, the session including the modem configuration information and user-specific session information; and

obtaining at least one token from the second access point, each token being related to dedicated modem configuration information, and wherein the token contained in the first message is one of the at least one token.

32. The method of claim 30, further comprising:

exchanging data with a second access point according to a session previously established for the user terminal.

33. An apparatus in a communication network, comprising:

means for sending a first message from a user terminal to a first access point to establish a connection, the first message including a token indicating modem configuration information to be used for the connection;

means for receiving a second message from the first access point indicating a successful connection establishment based on the token; and

means for exchanging data with the first access point according to the modem configuration information.

34. The apparatus of claim 33, further comprising:

means for establishing a session with a second access point, the session including the modem configuration information and user-specific session information; and

means for obtaining the token associated with the modem configuration information from the second access point.

35. The apparatus of claim 33, further comprising:

means for exchanging data with a second access point based on a session previously established for the user terminal.