for a better understanding of the invention , the following detailed description refers to the accompanying drawings , wherein preferred exemplary embodiments of the present invention are illustrated and described . in addition , the reference numbers used to identify key elements of the invention in the drawings are consistent throughout this description . the present invention involves a technique which improves the performance of a mobile unit or mobile terminal ( herein referred to as a “ mu ”) in a radio telecommunication system , particularly during hand - over , wherein the mu becomes disconnected from a first stationary unit ( herein referred to as “ suk k ”) and connected to another stationary unit ( herein referred to as “ su k + l ”) and wherein su k and su k + 1 belong to a common administrative network domain that is under the control of a common security policy . the present invention accomplishes this by reusing one or more previously established security associations to support the newly formed connection between the mu and su k + 1 . by reusing these previously established security associations , the mu and su k + 1 need not go through the time consuming task of renegotiating the security associations ( herein referred to as “ sa ” s ) each time the mu changes it &# 39 ; s point of connection ( e . g ., undergoes hand - over ) within the administrative domain . the present invention is of particularly importance where the communicating entities ( e . g ., the mu and su k + 1 ) exhibit low to medium level computational power , and where the mu is especially mobile and frequently undergoing hand - over . in accordance with the present invention , each of a number of stationary units ( sus ) associated with the same administrative domain , and thus under the control of a common security policy , are managed in an identical manner with respect to the sas that are employed to protect the communication between the mu and the various sus . accordingly , the set of sas that are established between the mu and any one of the various sus belonging to that administrative domain can be reused by any one of the other sus associated with that administrative domain , if and when the mu is handed - over to one of these other sus . as previously stated , reuse of the previously established sas will improve the performance of the mu during hand - over , without sacrificing communication security . however , depending upon the extent to which mu performance improvement is desired , two exemplary embodiments of the present invention are described herein below . in accordance with a first exemplary embodiment of the present invention , herein referred to as the partial sa reuse embodiment , a previously established internet security association and key management protocol ( isakmp ) sa is reused each time the mu is handed - over to another su ( i . e ., su k + 1 ) in the administrative domain . more specifically , when the mu establishes a connection with a su in the administrative domain for the first time , the internet key exchange ( ike ) phase 1 negotiation , which is used for establishing the isakmp sa , and the ike phase 2 negotiation , which is used for establishing the ip sec sas , are carried out in accordance with the various standards set forth by the internet engineering task force ( ietf ). however , as the mobile unit moves about , and is handed - over to another su ( i . e ., su k + 1 ) associated with the same administrative domain , the previously established isakmp sa is reused by the mu and su k + 1 . nevertheless , the mu and su k + 1 still must conduct an ike phase 2 negotiation ; that is , the mu and su k + l must renegotiate the ip sec sas . because the ike phase 1 sa negotiation process is far more time consuming relative to the ike phase 2 negotiation process , the reuse of the isakmp sa greatly improves the performance of the mu during hand - over . in accordance with a second exemplary embodiment of the present invention , herein referred to as the full sa reuse embodiment , the previously established isakmp sa and the previously established ip sec sas are reused each time the mu undergoes hand - over from one su ( i . e ., su k ) to another su ( i . e ., su k + 1 ) in the administrative domain . as stated above , when a mu connects with a su in the administrative domain for the first time , the isakmp sa and the ip sec sas are established in accordance with the ike phase 1 and the ike phase 2 negotiation processes respectively . however , unlike the partial sa reuse embodiment described above , subsequent hand - overs result in the reuse of both the previously established isakmp sa and the previously established ip sec sas . thus , the entire ike sa negotiation process , including phase 1 and phase 2 , is avoided . therefore , the mu and su k + 1 can begin communicating with each other almost immediately after the isakmp sa and the ip sec sas are transferred from su k to su k + 1 . consequently , the hand - over procedure is accomplished in a seamless or near seamless fashion . in general , the full sa reuse embodiment provides greater mu performance enhancement during hand - over than does the partial sa reuse embodiment . that is because the mu and su k + 1 need not renegotiate any sas . why then might a network administrator opt to implement the partial sa reuse embodiment over the full sa reuse embodiment ? one reason might be that the network administrator does not want the various sus associated with an administrative domain to share the same session keys ( i . e ., encryption and authentication keys ) as specified by the ip sec sas . if , for example , all the sus associated with the administrative domain share the same session keys and just one of the sus is compromised , an attacker can probably compromise communications between the mu and any of the sus associated with the administrative domain . as stated previously , a specific ip sec sa is uniquely identified by a security parameter index ( spi ), in combination with a destination ip address , and a particular security protocol ( e . g ., the authentication header protocol or the encapsulating security payload protocol ). as such , a common ip address is needed for all sus in the administrative domain , in order to reuse an ip sec sa . in accordance with the full sa reuse embodiment , this common ip address may be assigned to each su as an alias ip address . however , under certain circumstances , a network administrator may not want to assign a common ip address to each su . if this is the case , the network administrator is likely to opt the partial sa reuse embodiment rather than the full sa reuse embodiment . when a mu is handed - over from one su ( e . g . su k ) to another su ( e . g . su k + 1 ), the sa attributes corresponding to the isakmp sa and the sa attributes corresponding to the ip sec sas , depending upon whether the partial sa reuse embodiment or the full sa reuse embodiment is being employed , must be transferred from su k to su k + 1 . this transfer of sa attributes from su k to su k + 1 may be accomplished in accordance with any one of a number of exemplary techniques . fig1 illustrates one such technique herein referred to as the direct transfer technique . according to the direct transfer technique , a mu 101 undergoes a hand - over from su k 105 to su k + 1 110 , as illustrated by the directional arrow marked “ 1 ”. next , su k + 1 110 contacts su k 105 by sending a sa request message , as illustrated by the directional arrow marked “ 2 ”. the sa request message specifically requests those sas associated with the mu 101 . accordingly , the sa request message must contain an identifier code for the mu 101 . su k 105 then replies to the sa request message by sending the appropriate sa attributes to su k + 1 110 , as illustrated by the directional arrow marked “ 3 ”. in addition to the procedural steps described above , the direct transfer technique illustrated in fig1 might also involve the step of verifying that su k belongs to the same administrative domain as su k + 1 . to accomplish this , each su associated with the administrative domain might maintain a list containing all ip addresses associated with the administrative domain . su k + 1 can then perform the required verification by simply checking to see if the ip address associated with su k is on the list . alternatively , if administrative domain corresponds with an ip network or subnet , su k + 1 can simply compare the network identification portion of su k &# 39 ; s ip address with the network identification portion of it &# 39 ; s own ip address . if they match , su k + 1 has verified that su k , in fact , belongs to the same administrative domain . if su k + 1 determines that su k does not belong to the same administrative domain , then the mu and su k + 1 may be required to renegotiate the isakmp sa and the ip sec sas , unless the attributes associated with the isakmp sa and the ip sec sas were stored , for example , in a database , as illustrated in fig2 during a previous connection between the mu and any one of the sus associated with the administrative domain to which su k + 1 belongs . fig2 illustrates an alternative technique for transferring the appropriate sa attributes . this alternative technique is herein referred to as the intermediate storage technique . the intermediate storage technique may be preferable where the network configuration makes it difficult to identify suk , or when direct communication between su k and su k + 1 is difficult or undesirable . in accordance with this alternative technique , as shown in fig2 a mu 201 undergoes a hand - over from su k 205 to su k + 1 210 , as illustrated by the directional arrow marked “ 1 ”. prior to , simultaneous to , or if necessary , subsequent to the hand - over , su k transfers the appropriate sas associated with the mu 201 to a database ( dbs ) 215 , as indicated by the directional arrow marked “ 2 ”. su k + 1 210 then sends a sa request message to the dbs 215 , as illustrated by the directional arrow marked “ 3 ”. as in the direct transfer technique , the sa request message contains an identifier code that specifically identifies the mu 201 . thus , the dbs 215 can reply to the sa request message by sending the appropriate sas , associated with the mu 201 , to su k + 1 210 , as illustrated by the directional arrow marked “ 4 ”. as one skilled in the art will readily appropriate , the sas contain sensitive information ( e . g ., session keys ). accordingly , the sa information that is transferred from su k to su k + 1 , using the direct transfer or the intermediate storage technique , should be protected . therefore , encryption and authentication mechanisms might be employed to ensure confidentiality and authenticity for this information . fig3 illustrates , more specifically , the sa attributes that might be transferred from su k to su k + 1 , if the partial sa reuse embodiment is employed . as illustrated , su k 105 , upon receiving a sa request message from su k + 1 110 , as indicated by the directional arrow marked “ 2 ”, sends a reply message 305 to su k + 1 110 , wherein the reply message 305 contains the information necessary to define the following isakmp sa attributes : the isakmp sa lifetime ; the isakmp session keys , including the isakmp session key for authentication and the isakmp session key for encryption ; keying material , which is required for deriving the ip sec session keys ; the last ike phase 1 cbc ( i . e ., cipher block chaining ) output block for generating an initialization vector which , in turn , is needed for the encryption of the first ike phase 2 message . although fig3 indicates that the sa attributes are being transferred in accordance with the direct transfer technique described above , it will be readily apparent to one skilled in the art that the intermediate storage technique may be employed in the alternative . fig4 illustrates the sa attributes that might be transferred from su k 105 to su k + 1 110 , in addition to the sa attributes identified in fig3 if the full sa reuse embodiment is employed . as illustrated in fig4 su k 105 , upon receiving a sa request message from su k + 1 110 , as indicated by the directional arrow marked “ 2 ” sends a reply message 405 to su k + 1 110 , wherein the reply message 405 contains the information necessary to define the isakmp sa attributes identified above in fig3 and the information necessary to define the following ip sec sa attributes : the ip sec sa lifetime ; the ip sec protocols being used , that is , the authentication header and / or encapsulating security payload protocols ; the ip sec protocol mode , that is , the transport mode or the tunnel mode ; the security parameter index ( es ); the ip sec session keys , including the session keys for authentication and encryption , as well as their respective algorithms ; the last cbc output block prior to hand - over , which is used as the initialization vector for encryption of the first ip packet subsequent to hand - over ; and the value of the sequence number , in accordance with the authentication header protocol or the encapsulating security payload protocol , just prior to hand - over , as this value plus 1 will be the initial value of the sequence number after hand - over for anti - relay checking purposes . as was the case in fig3 the transfer of sa attributes in fig4 is accomplished in accordance with the direct transfer technique described above . however , it will be understood that the sa attributes may be transferred in accordance with the intermediate storage technique , also described above . as stated previously , the first time a mu connects to any su in a given administrative domain , an ike phase 1 negotiation and an ike phase 2 negotiation must be accomplished , thereby establishing the isakmp sa and the ip sec sas respectively . however , in accordance with another aspect of the present invention , the sa attributes associated with the isakmp sa and the ip sec sas may be stored for a period of time , for example , a period of time equivalent to the isakmp sa lifetime and the ip sec sa lifetime respectively . the sa attributes might be stored in a database , such as the database 215 illustrated in fig2 . by storing the sa attributes , the mu might avoid having to renegotiate the isakmp sa and the ip sec sas if the mu becomes disassociated with the administrative domain , for example , by being handed - over to a su which is not associated with the administrative domain , and then the mu becomes reassociated with the administrative domain , for example , by being handed back - over to a su associated with the administrative domain , before the aforementioned period of time expires . in accordance with this aspect of the invention , the transfer of sa attributes to su k + 1 might be accomplished in much the same way as the intermediate storage technique illustrated in fig2 but for the fact that the mu is handed - over to a su associated with another administrative domain during an interim period between the time the mu is connected to su k and the time the mu is connected to su k + 1 . fig5 illustrates a procedure for transferring sa attribute control messages , in accordance with an exemplary embodiment of the present invention , using encryption and authentication techniques to protect the sa attributes during transfer . while the procedure illustrated in fig5 involves the intermediate storage technique , described above with reference to fig2 one skilled in the art will readily appreciate that a similar procedure could be applied to the direct transfer technique , described above with reference to fig1 . the procedure illustrated in fig5 initially begins with the mu undergoing a hand - over procedure from the stationary unit suk to the stationary unit su k + 1 , as indicated by the directional arrow marked “ 1 ”, wherein su k and su k + 1 are associated with the same administrative domain . therefore , suk and su k + 1 are subject to the same security policy . then , at some point during the hand - over procedure , su k transfers the sa attribute control message to the dbs , as indicated by the directional arrow marked “ 2 ”. as shown , the sa attribute control message contains a mu identification code ( id mu ); the sa attributes ( enc ksa ), which are encrypted using an encryption key k sa ; a time stamp ( t ); and a hash value ( hash kdb ). the purpose of the mu identification code ( id mu ) is to identify the sa attributes ( i . e ., enc ksa ) as being associated with the mu . the purpose of the time stamp ( t ) is inform the dbs as to the period of time that has elapsed since the su k sent the sa control message . if a significant period of time has elapsed , the dbs may be designed to reject the sa attribute control message to protect against unauthorized replay . while the mu identification code a ( id mu ) and the time stamp ( t ) are not typically encrypted , the sa attributes are encrypted using an encryption key ksa , which is shared by each of the sus associated with the administrative domain . the hash value ( hash kdb ) is used for authentication purposes , and it is derived using an authentication key k db and as a function of the mu identification code ( id mu ), the sa attributes ( enc ksa ) and the time stamp ( t ). the authentication key k db , like the encryption key k sa , is shared by each of the sus associated with the administrative domain . in addition , it is shared by the dbs . as stated , su k transfers the sa attribute control message , containing the mu identification code ( id mu ), the encrypted sa attributes ( enc ksa ), the time stamp ( t ), and the hash value ( hash kdb ), to the dbs . upon receiving the sa attribute control message , the dbs recalculates the hash value as a function of the received values for the mu identification code ( id mu ), the sa attributes ( enc ksa ), and the time stamp ( t ), and based on the authentication key k db . then dbs then compares the recalculated hash value with the received hash value . if the two values are equal ( i . e ., if the two values match ), the dbs authenticates su k , and accepts the sa attribute control message . the dbs then stores the encrypted sa attributes ( enc ska ) along with the mu identification code ( id mu ). further in accordance with the procedure illustrated in fig5 su k + 1 now issues a sa attribute request message to the dbs , as indicated by the directional arrow marked “ 3 ”, wherein the sa attribute request message contains the mu identification code ( id mu ). in response , the dbs transfers to su k + 1 the encrypted sa attributes ( enc ksa ) that correspond to the mu identification code ( id mu ) contained in the sa attribute request message . by applying the encryption key k sa to the sa attributes ( enc ksa ), su k + 1 can decipher the encrypted sa attributes . the present invention has been described with reference to a preferred embodiment . however , it will be readily apparent to those skilled in the art that it is possible to embody the invention in specific forms other than as described above without departing from the spirit of the invention . the preferred embodiments are illustrative and should not be considered restrictive in any way . the scope of the invention is given by the appended claims , rather than the preceding description , and all variations and equivalents which fall within the range of the claims are intended to be embraced therein .