Context fetching after inter-system handover

Systems and methodologies are described that facilitate fetching a native security context between network nodes in a core network after an inter-system handover of a mobile device. For instance, a mobility message that is integrity protected by a security context (e.g., the native security context, a mapped security context, . . . ) can be obtained at a network node from the mobile device. Further, the network node can send a request to a disparate network node within a core network. The request can include information that can be used by the disparate network node to establish that the mobile device is authenticated. Moreover, the native security context can be received from the disparate network node in response to the request. Accordingly, the native security context need not be recreated between the network node and the mobile device.

BACKGROUND

The following description relates generally to wireless communications, and more particularly to implementing context fetching between network nodes after inter-system handover in a wireless communication environment.

Wireless communication systems are widely deployed to provide various types of communication content such as, for example, voice, data, and so on. Typical wireless communication systems can be multiple-access systems capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, . . . ). Examples of such multiple-access systems can include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and the like. Additionally, the systems can conform to specifications such as third generation partnership project (3GPP), 3GPP long term evolution (LTE), ultra mobile broadband (UMB), and/or multi-carrier wireless specifications such as evolution data optimized (EV-DO), one or more revisions thereof, etc.

Generally, wireless multiple-access communication systems can simultaneously support communication for multiple mobile devices. Each mobile device can communicate with one or more base stations via transmissions on forward and reverse links. The forward link (or downlink) refers to the communication link from base stations to mobile devices, and the reverse link (or uplink) refers to the communication link from mobile devices to base stations. Further, communications between mobile devices and base stations can be established via single-input single-output (SISO) systems, multiple-input single-output (MISO) systems, multiple-input multiple-output (MIMO) systems, and so forth. In addition, mobile devices can communicate with other mobile devices (and/or base stations with other base stations) in peer-to-peer wireless network configurations.

In a wireless communication network, a mobile device can register with a network node of a core network to establish a security relationship. A security context for the security relationship can be generated, and the security context can be retained by the mobile device and the network node. The security context can be utilized, for example, to integrity protect a message sent by the mobile device to the network node; the message can be sent over the air to a base station, and the base station can thereafter send the message to the network node of the core network. The network node can check the integrity of the received message by employing the security context. Following this example, the security context can include a key shared between the network node and the mobile device.

Moreover, the mobile device can handover between disparate types of systems. According to an example, the mobile device can establish a security relationship with a first network node of a first type of system, thereby yielding a first security context that can be retained by both the mobile device and the first network node of the first type of system. Thereafter, the mobile device can handover to a second type of system. Thus, a security relationship with a second network node of the second type of system can be established, and a second security context corresponding to this security relationship can be retained by both the mobile device and the second network node of the second type of system. Moreover, the mobile device and the first network node of the first type of system can continue to retain the first security context subsequent to the handover to the second type of system.

Further, the mobile device can again handover back to the first type of system. As part of the handover procedure, a mapped security context for the first type of system can be derived from the second security context for the second type of system. Moreover, the mobile device can send a message to a third network node included in the core network of the first type of system, where the third network node can differ from the first network node that has the first security context for the mobile device. Accordingly, the third network node can attempt to fetch the first security context from the first network node rather than causing the mobile device to reestablish the security relationship, and thus, recreating the first security context for the first type of system can be mitigated. Recreation of the first security context can be costly in terms of latency, processing, bandwidth usage, etc. due to retrieval of authentication materials (e.g., from a Home Subscriber Server (HSS), . . . ), effectuating authentication of the mobile device, and so forth. By fetching the first security context retained by the first network node instead of recreating such security context, these costs can be diminished. When employing convention techniques, however, a network node oftentimes is unable to fetch a security context from a disparate network node within a core network associated with a type of system after an inter-system handover.

SUMMARY

In accordance with one or more embodiments and corresponding disclosure thereof, various aspects are described in connection with facilitating fetching of a native security context between network nodes in a core network after an inter-system handover of a mobile device. For instance, a mobility message that is integrity protected by a security context (e.g., the native security context, a mapped security context, . . . ) can be obtained at a network node from the mobile device. Further, the network node can send a request to a disparate network node within a core network. The request can include information that can be used by the disparate network node to establish that the mobile device is authenticated. Moreover, the native security context can be received from the disparate network node in response to the request. Accordingly, the native security context need not be recreated between the network node and the mobile device.

According to related aspects, a method is described herein. The method can include receiving a mobility message integrity protected by a security context at a network node from a mobile device after an inter-system handover of the mobile device. Further, the method can include sending a request for a native security context to a disparate network node within a core network, the request includes information utilized by the disparate network node to ensure that the mobile device is authenticated. Moreover, the method can include receiving the native security context from the disparate network node in response to the request.

Another aspect relates to a wireless communications apparatus. The wireless communications apparatus can include at least one processor. The at least one processor can be configured to obtain a mobility message integrity protected by a security context at a network node from a mobile device after an inter-system handover of the mobile device. Moreover, the at least one processor can be configured to transmit a request for a native security context to a disparate network node, the request includes information utilized by the disparate network node to verify that the mobile device is authenticated. Further, the at least one processor can be configured to obtain the native security context from the disparate network node in response to the request.

Yet another aspect relates to an apparatus. The apparatus can include means for obtaining a mobility message integrity protected by a security context from a mobile device after an inter-system handover of the mobile device. Moreover, the apparatus can include means for fetching a native security context from a disparate network node within a core network utilizing a request that includes information employed by the disparate network node to establish that the mobile device is authenticated.

Still another aspect relates to a computer program product that can comprise a computer-readable medium. The computer-readable medium can include code for causing at least one computer to receive a mobility message integrity protected by a security context from a mobile device after an inter-system handover of the mobile device. Further, the computer-readable medium can include code for causing at least one computer to fetch a native security context from a disparate network node within a core network utilizing a request that includes information employed by the disparate network node to establish that the mobile device is authenticated.

Yet another aspect relates to an apparatus that can include an authentication component that yields information to be utilized by a disparate network node to verify that a mobile device is authenticated. The apparatus can also include a context fetch component that generates a request for a native security context from the disparate network node in response to a mobility message received from the mobile device, the request includes the information to be utilized by the disparate network node to verify that the mobile device is authenticated.

In accordance with other aspects, a method is described herein. The method can include receiving a request for a native security context of a mobile device retained in memory of a network node from a differing network node within a core network, the request responsive to a mobility message integrity protected by a security context from the mobile device after an inter-system handover of the mobile device. The method can also include authenticating the mobile device based at least in part upon information included in the request. Moreover, the method can include sending the native security context to the differing network node when the mobile device is authenticated.

Another aspect relates to a wireless communications apparatus. The wireless communications apparatus can include at least one processor. The at least one processor can be configured to receive a request for a native security context of a mobile device retained in memory of a network node from a differing network node within a core network, the request responsive to a mobility message integrity protected by a security context from the mobile device after an inter-system handover of the mobile device; authenticate the mobile device based at least in part upon information included in the request; and send the native security context to the differing network node when the mobile device is authenticated.

Yet another aspect relates to an apparatus. The apparatus can include means for obtaining a request for a native security context of a mobile device from a differing network node within a core network. Still yet, the apparatus can include means for authenticating the mobile device based at least in part upon information included in the request. Further, the apparatus can include means for transmitting the native security context to the differing network node when the mobile device is authenticated.

Still another aspect relates to a computer program product that can comprise a computer-readable medium. The computer-readable medium can include code for causing at least one computer to obtain a request for a native security context of a mobile device from a differing network node within a core network. Moreover, the computer-readable medium can include code for causing at least one computer to authenticate the mobile device based at least in part upon information included in the request. Further, the computer-readable medium can include code for causing at least one computer to transmit the native security context to the differing network node when the mobile device is authenticated.

Yet another aspect relates to an apparatus that can include an authentication component that authenticates a mobile device based at least in part upon information included in a request for a native security context received from a differing network node within a core network. The apparatus can also include a context forward component that sends the native security context to the differing network node when the mobile device is authenticated.

According to other aspects, a method is described herein. The method can include generating a mobility message after an inter-system handover. Moreover, the method can include protecting an integrity of the mobility message utilizing a security context to yield an integrity protected mobility message. Further, the method can include transmitting the integrity protected mobility message intended for a network node in a core network, the integrity protected mobility message utilized by the network node to fetch a native security context from a disparate network node.

Another aspect relates to a wireless communications apparatus. The wireless communications apparatus can include at least one processor. The at least one processor can be configured to generate a mobility message after an inter-system handover. Moreover, the at least one processor can be configured to protect an integrity of the mobility message utilizing a security context to yield an integrity protected mobility message. Further, the at least one processor can be configured to transmit the integrity protected mobility message intended for a network node in a core network, the integrity protected mobility message utilized by the network node to fetch a native security context from a disparate network node.

Yet another aspect relates to an apparatus. The apparatus can include means for yielding a mobility message after an inter-system handover; means for protecting an integrity of the mobility message employing a security context to generate an integrity protected mobility message; and means for transmitting the integrity protected mobility message, the integrity protected mobility message being utilized by a network node to fetch a native security context from a disparate network node in a core network.

Still another aspect relates to a computer program product that can comprise a computer-readable medium. The computer-readable medium can include code for causing at least one computer to yield a mobility message after an inter-system handover. The computer-readable medium can further include code for causing at least one computer to protect an integrity of the mobility message employing a security context to generate an integrity protected mobility message. Moreover, the computer-readable medium can include code for causing at least one computer to transmit the integrity protected mobility message, the integrity protected mobility message being utilized by a network node to fetch a native security context from a disparate network node in a core network.

Yet another aspect relates to an apparatus that can include an area update component that yields a mobility message after an inter-system handover. The apparatus can also include an integrity protection component that protects an integrity of the mobility message using one of a native security context or a mapped security context to yield an integrity protected mobility message for transmission to a network node in a core network and utilized by the network node to fetch the native security context from a disparate network node.

DETAILED DESCRIPTION

Furthermore, various aspects are described herein in connection with a terminal, which can be a wired terminal or a wireless terminal. A terminal can also be called a system, device, subscriber unit, subscriber station, mobile station, mobile, mobile device, remote station, remote terminal, access terminal, user terminal, terminal, communication device, user agent, user device, or user equipment (UE). A wireless terminal can be a cellular telephone, a satellite phone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, a computing device, or other processing devices connected to a wireless modem. Moreover, various aspects are described herein in connection with a base station. A base station can be utilized for communicating with wireless terminal(s) and can also be referred to as an access point, a Node B, an Evolved Node B (eNode B, eNB), or some other terminology.

Single carrier frequency division multiple access (SC-FDMA) utilizes single carrier modulation and frequency domain equalization. SC-FDMA has similar performance and essentially the same overall complexity as those of an OFDMA system. A SC-FDMA signal has lower peak-to-average power ratio (PAPR) because of its inherent single carrier structure. SC-FDMA can be used, for instance, in uplink communications where lower PAPR greatly benefits access terminals in terms of transmit power efficiency. Accordingly, SC-FDMA can be implemented as an uplink multiple access scheme in 3GPP Long Term Evolution (LTE) or Evolved UTRA.

Referring now toFIG. 1, a wireless communication system100is illustrated in accordance with various embodiments presented herein. Wireless communication system100comprises a base station102that can include multiple antenna groups. For example, one antenna group can include antennas104and106, another group can comprise antennas108and110, and an additional group can include antennas112and114. Two antennas are illustrated for each antenna group; however, more or fewer antennas can be utilized for each group. Base station102can additionally include a transmitter chain and a receiver chain, each of which can in turn comprise a plurality of components associated with signal transmission and reception (e.g., processors, modulators, multiplexers, demodulators, demultiplexers, antennas, etc.), as will be appreciated by one skilled in the art.

Base station102can communicate with one or more mobile devices such as mobile device116and mobile device122; however, it is to be appreciated that base station102can communicate with substantially any number of mobile devices similar to mobile devices116and122. Mobile devices116and122can be, for example, cellular phones, smart phones, laptops, handheld communication devices, handheld computing devices, satellite radios, global positioning systems, PDAs, and/or any other suitable device for communicating over wireless communication system100. As depicted, mobile device116is in communication with antennas112and114, where antennas112and114transmit information to mobile device116over a forward link118and receive information from mobile device116over a reverse link120. Moreover, mobile device122is in communication with antennas104and106, where antennas104and106transmit information to mobile device122over a forward link124and receive information from mobile device122over a reverse link126. In a frequency division duplex (FDD) system, forward link118can utilize a different frequency band than that used by reverse link120, and forward link124can employ a different frequency band than that employed by reverse link126, for example. Further, in a time division duplex (TDD) system, forward link118and reverse link120can utilize a common frequency band and forward link124and reverse link126can utilize a common frequency band.

Each group of antennas and/or the area in which they are designated to communicate can be referred to as a sector of base station102. For example, antenna groups can be designed to communicate to mobile devices in a sector of the areas covered by base station102. In communication over forward links118and124, the transmitting antennas of base station102can utilize beamforming to improve signal-to-noise ratio of forward links118and124for mobile devices116and122. Also, while base station102utilizes beamforming to transmit to mobile devices116and122scattered randomly through an associated coverage, mobile devices in neighboring cells can be subject to less interference as compared to a base station transmitting through a single antenna to all its mobile devices.

Base station102can be a bridge between mobile devices116and122and a core network (not shown). For instance, when a mobile device (e.g., mobile device116, mobile device122, . . . ) registers with a core network of a particular type of system to yield a security context, messages can be exchanged between the mobile device and a network node of the core network via base station102. Moreover, mobility messages associated with an area update procedure (e.g., Tracking Area Update (TAU) procedure, . . . ) can be integrity protected with the security context and transferred between the mobile device and the core network (e.g., the network node, a disparate network node, . . . ) via base station102.

For example, base station102can be part of an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) and the core network of a Long Term Evolution (LTE) system can be an Evolved Packet System (EPS) core network. The EPS core network can include network nodes such as, for instance, one or more Mobility Management Entities (MMES), one or more Serving Gateways (SGWs), one or more Packet Data Network Gateways (PDN GWs), one or more Authentication, Accounting and Authorization/Home Subscriber Servers (AAA/HSSs), and so forth. Base station102can be coupled to an MME via an S1-MME interface, and base station102can be coupled to an SGW via an S1-U interface. Following this example, a mobile device (e.g., an E-UTRAN capable mobile device such as mobile device116, mobile device122, . . . ) can establish a security relationship with the EPS core network to yield a corresponding security context by registering with an MME. Base station102can transport messages transferred between the mobile device and the MME utilized for establishing the security relationship and/or associated with an area update procedure.

According to another example, base station102can be part of a UMTS Terrestrial Radio Access Network (UTRAN) or a GSM Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN). Further, the core network associated with a UTRAN/GERAN system can include one or more Mobile Switching Centers (MSCs), one or more Serving General Packet Radio Service (GPRS) Support Nodes (SGSNs), and so forth. Pursuant to this example, a mobile device (e.g., a UTRAN capable mobile device such as mobile device116, mobile device122, . . . ) can establish a security relationship with an SGSN to yield a corresponding security context by registering with such SGSN. Accordingly, base station102can transport messages transferred between the mobile device and the SGSN employed for establishing the security relationship and/or associated with an area update procedure. Further, any disparate type of system other than an E-UTRAN system or a UTRAN/GERAN system is contemplated to fall within the scope of the hereto appended claims.

Now turning toFIG. 2, illustrated is a system200that supports fetching a security context between network nodes in a wireless communication environment. System200includes a mobile device202. Mobile device202can transmit and/or receive information, signals, data, instructions, commands, bits, symbols, and the like. Moreover, although not shown, it is contemplated that system200can include any number of mobile devices similar to mobile device202. Mobile device202can communicate with one or more base stations (not shown) (e.g., base station102ofFIG. 1, . . . ) via the forward link and/or reverse link. The one or more base stations can each transmit and/or receive information, signals, data, instructions, commands, bits, symbols, and the like. The one or more base stations can be associated with different types of system (e.g., a first subset of base stations can be from a first type of radio access network and a second subset of base stations can be from a second type of radio access network, . . . ).

System200can further include a plurality of core networks. As depicted, system200includes core network A204and core network B206; yet, it is contemplated that any number of additional core networks can be included in system200and are intended to fall within the scope of the hereto appended claims. Core network A204and core network B206can each be associated with a respective type of system. By way of example, core network A204can be an EPS core network associated with an E-UTRAN system, and core network B206can be a core network associated with a UTRAN/GERAN system; yet, it is contemplated that any disparate number and/or type of system is intended to fall within the scope of the claimed subject matter.

Core network A204can include a plurality of respective network nodes, and core network B206can include a plurality of respective network nodes. In the illustrated example, core network A204can include network node1208and network node2210, and core network B206can include network node3212. Yet, it is contemplated that the claimed subject matter is not limited to this example since core network A204can include substantially any number of network nodes and/or core network B206can include substantially any number of network nodes.

Moreover, a security relationship can be established between mobile device202and core network A204as well as between mobile device202and core network B206. According to an example, mobile device202could have previously camped on a base station (not shown) associated with network node2210of core network A204. Thus, mobile device202could have registered with network node2210to yield a native security context A (e.g., a security context for core network A204, . . . ). The native security context A can be retained by both mobile device202and network node2210(e.g., upon registration, subsequent to handing over to a disparate type of system such as a system associated with core network B206, . . . ). Further, mobile device202could have also previously camped on a base station (not shown) associated with network node3212of core network B206. Hence, mobile device202could have registered with network node3212to generate a native security context B (e.g., a security context for core network B206, . . . ). Moreover, the native security context B can be retained by both mobile device202and network node3212. Further, the native security context A can be more secure than the native security context B.

Network node1208can further include an inter-system handover component214. Inter-system handover component214can interact with mobile device202to effectuate a handover procedure where mobile device202hands over from a system associated with core network B206to a system associated with core network A204. Further, inter-system handover component214and mobile device202(e.g., an inter-system handover component (not shown) of mobile device202, . . . ) can create a mapped security context B-A derived from native security context B that mobile device202utilized in the system associated with core network B206. The mapped security context B-A can be a security context corresponding to core network A204, yet generated from a native security context corresponding to core network B206. For example, since mobile device202hands over from the system associated with core network B206with a security relationship (e.g., native security context B, . . . ) established with network node3, then network node3212can pass information to network node1208of core network A204used to derive the mapped security context B-A. Accordingly, after a handover from the system associated with core network B206to the system associated with core network A204, the mapped security context B-A can be yielded by inter-system handover component214and retained by both network node1208and mobile device202.

The native security context B, from which the mapped security context B-A is derived, can be weaker than the native security context A; thus, the native security context A can be more secure (e.g., higher level of trust, . . . ) as compared to the native security context B or the mapped security context B-A. According to an example, keys of the native security context B can be passed within the system associated with core network B206. Thus, the keys of the native security context B can be passed to radio network elements from network node3212. In contrast, keys of the native security context A can be retained in core network A204and not passed elsewhere. Hence, the keys can be passed within core network A204(e.g., between network node1208and network node2210, . . . ), while the keys are not passed to radio network elements; rather, disparate keys can be derived from the keys of the native security context A retained within core network A204for distribution to radio network elements. It is to be appreciated, however, that the claimed subject matter is not limited to the foregoing example.

Mobile device202can further include an area update component216and an integrity protection component218. After the inter-system handover from the system associated with core network B206to the system associated with core network A204, area update component216of mobile device202can perform an area update procedure. The area update procedure effectuated by area update component216can be a TAU procedure or the like. Area update component216can generate a mobility message (e.g., a TAU request message, . . . ). Further, integrity protection component218can integrity protect the mobility message using the mapped security context B-A or the native security context A (e.g., depending upon the approach implemented as described herein, . . . ). For instance, integrity protection component218can compute a Message Authentication Code (MAC) from a counter, a key (e.g., from a corresponding security context, . . . ), and the mobility message (e.g., a clear text message, . . . ). The key can be from the mapped security context B-A or the native security context A depending upon the approach implemented as described herein. Moreover, the MAC can be appended to the mobility message by integrity protection component218to yield an integrity protected mobility message. It is further contemplated that the integrity protected mobility message can also include the counter. Area update component216can send the integrity protected mobility message to a newly camped upon base station (not shown). The base station can further transport the integrity protected mobility message to network node1208of core network A204corresponding to the base station.

The integrity protected mobility message can be received at network node1208. By way of example, if network node1208has retained the native security context A (not shown) (e.g., mobile device202previously registered with network node1208, the native security context A was previously fetched by network node1208, . . . ) and the integrity protected mobility message is integrity protected with the mapped security context B-A (e.g., by integrity protection component218, . . . ), then network node1208can send a response to mobile device202indicating that network node1208has the native security context A. Further, network node1208can signal to mobile device202to utilize the native security context A under the foregoing example scenario.

According to another example, network node1208can lack the native security context A. Thus, the integrity protected mobility message can be sent to network node1208(e.g., a new network node, . . . ), which is different from network node2210(e.g., an old network node, . . . ) that has the native security context A for mobile device202. In this case, network node1208can fetch a previously stored native security context A from network node2210.

Network node1208can further include an authentication component220and a context fetch component222. Moreover, network node2210can include an authentication component224and a context forward component226. Although not shown, it is contemplated that network node1208and network node2210can be substantially similar (e.g., network node1208can further include a context forward component similar to context forward component226, network node2210can further include an inter-system handover component similar to inter-system handover component214and/or a context fetch component similar to context fetch component222, . . . ).

Authentication component220and authentication component224can operate in conjunction employing one or more of the approaches described herein to authenticate mobile device202. Context fetch component222can send a message to network node2210to request the native security context A. The message transmitted by context fetch component222can be the integrity protected mobility message, a context request message, or the like. For example, the message transmitted by context fetch component222can include information yielded by authentication component220that can be utilized by authentication component224of network node2210to ensure, verify, establish, etc. that mobile device202is authenticated. When mobile device202is successfully authenticated by authentication component220and/or authentication component224, context forward component226can send the native security context A to network node1208. Alternatively, when authentication of mobile device202effectuated by authentication component220and/or authentication component224is unsuccessful, context forward component226can inhibit transmission of the native security context A to network node1208; rather, under such a scenario, a failure can be reported (e.g., to network node1208, . . . ).

According to an example, the mobility message can be integrity protected by integrity protection component218using the mapped security context B-A to generate the integrity protected mobility message. Moreover, additional parameters yielded based upon the native security context A retained by mobile device202can be included in the integrity protected mobility message (e.g., the additional parameters can be carried by optional information elements (IEs) in the integrity protected mobility message, . . . ) sent by area update component216to network node1208. For instance, authentication component220of network node1208can replace actual parameters (e.g., yielded based upon the mapped security context B-A, . . . ) from the integrity protected mobility message with the additional parameters (e.g., yielded based upon the native security context A, . . . ), and context fetch component222can send the modified integrity protected mobility message to network node2210. Authentication component224of network node2210can check the integrity of the modified integrity protected mobility message using the native security context A. If the message is successfully verified by authentication component224, then context forward component226can send the native security context A to network node1208. Alternatively, if the message is not successfully verified by authentication component224, then a failure can be reported to network node1208and sending of the native security context A can be inhibited. By way of another illustration, authentication component220of network node1208can cause context fetch component222to forward the integrity protected mobility message including the additional parameters carried by the optional IEs received from mobile device202, and authentication component224can replace the actual parameters with the additional parameters and thereafter check the integrity of the modified integrity protected mobility message using the native security context A. Further, context forward component226can transmit the native security context A to network node1208if the message is successfully verified by authentication component224; alternatively, a failure can be reported if the message is unsuccessfully verified.

Pursuant to a further example, the mobility message can be integrity protected by integrity protection component218using the mapped security context B-A to generate the integrity protected mobility message, which can be transmitted to network node1208by area update component216. Authentication component220can check the integrity of the integrity protected mobility message employing the mapped security context B-A. If the message is successfully verified by authentication component220, then context fetch component222can generate a context request message that includes an identifier corresponding to mobile device202and an indication that mobile device202has been successfully authenticated. Moreover, context fetch component222can send the context request message to network node2210. Authentication component224can evaluate the context request message to recognize that mobile device202has been successfully authenticated by network node1208. Further, context forward component226can send the native security context A to network node1208in response.

By way of yet another example, the mobility message can be integrity protected by integrity protection component218using the native security context A retained by mobile device202to generate the integrity protected mobility message, which can be transmitted to network node1208by area update component216. Network node1208can lack the native security context A when the integrity protected mobility message is received. Authentication component220of network node1208can cause context fetch component222to forward the integrity protected mobility message to network node2210. Authentication component224of network node2210can check the integrity of the integrity protected mobility message utilizing the native security context A. If the message is successfully verified by authentication component224, then context forward component226can send the native security context A to network node1208as part of a context response message; otherwise, if the message is not successfully verified by authentication component224, then a failure can be reported to network node1208as part of the context response message. Moreover, network node1208can send a message to mobile device202indicating which security context (e.g., the native security context A, the mapped security context B-A, . . . ) to utilize for subsequent messages (e.g., subsequent Non-Access Stratum (NAS) messages, . . . ) based upon the context response message received from network node2210.

Now referring toFIG. 3, illustrated is a system300that provides security protection of a TAU request message after inter-system handover from UTRAN/GERAN to E-UTRAN in a wireless communication environment. System300includes mobile device202(e.g., which can further include area update component216and integrity protection component218, . . . ), core network A204, and core network B206. Core network A204can be an EPS core network associated with an E-UTRAN system, and core network B206can be a core network associated with a UTRAN/GERAN system.

Core network A204can include an MME1302and an MME2304. MME1302can further include inter-system handover component214, authentication component220, and context fetch component222. Further, MME2304can include authentication component224and context forward component226. Although not shown, it is contemplated that MME1302and MME2304can be substantially similar to each other. Moreover, core network B206can include a SGSN306.

Mobile device202could have previously established a security relationship with core network A204(e.g., EPS core network, . . . ) by registering with MME2304. The security context for this security relationship can be called a native EPS security context (e.g., native security context A, . . . ), and can be stored by mobile device202and MME2304. Mobile device202and MME2304can continue to retain the native EPS security context when mobile device202moves to a UTRAN/GERAN system associated with core network B206.

Further, upon moving to the UTRAN/GERAN system, mobile device202could have previously established a security relationship with core network B206by registering with SGSN306. The security context for this security relationship can be called a native General Packet Radio Service (GPRS) security context (e.g., native security context B, . . . ).

When mobile device202hands over from the UTRAN/GERAN system to the E-UTRAN system, as part of the handover procedure, mobile device202and MME1302(e.g., inter-system handover component214, . . . ) can create an EPS security context derived from the native GPRS security context that mobile device202used in the UTRAN/GERAN system. The derived security context can be referred to as a mapped EPS security context (e.g., mapped security context B-A, . . . ).

After the handover from the UTRAN/GERAN system to the E-UTRAN system, mobile device202can perform a TAU procedure if mobile device202is not yet registered to the Tracking Area of a newly camped E-UTRAN cell (e.g., associated with MME1302, . . . ). More particularly, area update component216can yield a TAU request message. Further, integrity protection component218can integrity protect the TAU request message. According to an example, integrity protection component218can protect the TAU request message with the mapped EPS security context created during the handover procedure. By way of another example, integrity protection component218can protect the TAU request message with the native EPS security context retained by mobile device202, while MME1302can lack the native EPS security context at such time (e.g., prior to fetching from MME2304, . . . ).

Area update component216can send the TAU request message to MME1302, which differs from MME2304that has stored the native EPS security context for mobile device202. Thus, context fetch component222can send a message to fetch the native EPS security context from MME2304, and context forward component226can provide the native EPS security context to MME1302or a failure notification in response to the message.

Conventionally, fetching of the native EPS security context from MME2304typically is unable to be effectuated since a technique similar to an inter-MME TAU procedure is oftentimes implemented. For instance, in a common TAU procedure that causes a change of MMEs (e.g., inter-MME TAU procedure, . . . ), a TAU request message can be integrity protected by a current native EPS security context for a mobile device. A new MME that receives the TAU request message can send the entire TAU request message to an old MME to check the integrity protection of the message. If integrity protection fails, then the old MME does not send the current native EPS security context for the mobile device to the new MME; rather, a failure can be reported by the old MME to the new MME. Thus, conventional approaches where a TAU request message is integrity protected by a current security context which happens to be the mapped EPS security context, and not the native EPS security context that is being fetched, can be unable to be verified by MME2304when MME2304receives the TAU request message forwarded from MME1302. Under the conventional approach, MME2304can be unable to check the integrity protection of the forwarded message because MME2304lacks the mapped EPS security context (e.g., the current security context, . . . ). In contrast, the techniques described herein for fetching the native EPS security context (e.g., native security context A, . . . ) retained by MME2304can mitigate the foregoing.

FIGS. 4-7illustrate example systems that implement various approaches for fetching security contexts between network nodes after inter-system handover. Although not shown, it is to be appreciated that a combination of these approaches can be utilized. For these example systems (and similarly to the examples described inFIGS. 2 and 3), mobile device202could have previously established a security relationship with core network A204(e.g., by registering with network node2210, . . . ) to generate the native security context A (e.g., native EPS security context, . . . ) and could have previously established a security relationship with a disparate core network (not shown) (e.g., core network B206ofFIG. 2, . . . ) to generate the native security context B (e.g., GPRS security context, . . . ). Moreover, the native security context A can be more secure than the native security context B. Further, mobile device202can handover from a system (e.g., a UTRAN/GERAN system, . . . ) associated with the disparate core network to a system (e.g., an E-UTRAN system, . . . ) associated with core network A204. As part of the handover procedure, network node1208(e.g., inter-system handover component214, . . . ) and mobile device202can derive the mapped security context B-A (e.g., EPS security context, . . . ) from the native security context B (e.g., native GPRS security context, . . . ). After the handover, mobile device202can yield a mobility message with area update component216. Area update component216can employ a TAU procedure or the like (e.g., the mobility message can be a TAU request message, . . . ). Moreover, integrity protection component218can integrity protect the mobility message as described herein for transmission to network node1208via a base station (not shown).

Now referring toFIG. 4, illustrated is a system400that leverages additional parameters included in a mobility message for fetching a security context in a wireless communication environment. In system400, integrity protection component218of mobile device202can further include a parameter inclusion component402. Parameter inclusion component402can yield additional parameters that can be incorporated into an integrity protected mobility message for transmission to network node1208.

By way of illustration, area update component216can yield the mobility message. Integrity protection component218can utilize the mapped security context B-A (e.g., mapped EPS security context, . . . ) to integrity protect the mobility message. For instance, integrity protection component218can compute a NAS MAC from a NAS uplink counter (e.g., associated with the mapped security context B-A, . . . ), a key (e.g., from the mapped security context B-A, . . . ), and the mobility message (e.g., a clear text message, . . . ). Integrity protection component218can append the NAS MAC to the mobility message (e.g., along with the NAS uplink counter, . . . ) to yield an integrity protected mobility message. Further, parameter inclusion component402can compute a disparate NAS MAC from a disparate NAS uplink counter (e.g., associated with the native security context A retained by mobile device202, . . . ), a disparate key (e.g., from the native security context A retained by mobile device202, . . . ), and the mobility message. Parameter inclusion component402can further incorporate the disparate NAS MAC and the disparate NAS uplink counter associated with the native security context A retained by mobile device202in optional IEs in the integrity protected mobility message. Moreover, area update component216can transmit the integrity protected mobility message with the optional IEs that carry the disparate NAS MAC and the disparate NAS uplink counter associated with the native security context A.

Network node1208can obtain the integrity protected mobility message with the optional IEs that carry the disparate NAS MAC and the disparate NAS uplink counter associated with the native security context A. Authentication component220can further include a parameter exchange component404that can exchange parameters from the integrity protected mobility message with parameters carried by the optional IEs. More particularly, parameter exchange component404can substitute the NAS MAC and the NAS uplink counter from the integrity protected mobility message corresponding to the mapped security context B-A (e.g., the NAS MAC yielded based upon a key from the mapped security context B-A, the NAS uplink counter associated with the mapped security context B-A, . . . ) with the disparate NAS MAC and the disparate NAS uplink counter associated with the native security context A carried by the optional IEs to yield a modified integrity protected mobility message.

Context fetch component222can thereafter send the modified integrity protected mobility message to network node2210. Authentication component224of network node2210can further include an integrity evaluation component406that can check an integrity of the modified integrity protected mobility message utilizing the native security context A. If the integrity check by integrity evaluation component406is successful, then context forward component226can send the native security context A to network node1208. Alternatively, if the integrity check by integrity evaluation component406is unsuccessful, then a failure can be reported to network node1208and sending of the native security context A to network node1208can be inhibited.

Turning toFIG. 5, illustrated is another system500that utilizes additional parameters included in a mobility message for fetching a security context in a wireless communication environment. Similar to system400ofFIG. 4, integrity protection component218of mobile device202can further include parameter inclusion component402. Integrity parameter component218can employ the mapped security context B-A to integrity protect the mobility message. Parameter inclusion component402can yield the additional parameters (e.g., the disparate NAS MAC and the disparate NAS uplink counter based upon the native security context A, . . . ), which can be incorporated in optional IEs in the integrity protected mobility message. Thus, area update component216can transmit the integrity protected mobility message (e.g., yielded by integrity protection component218utilizing the mapped security context B-A, . . . ) with the optional IEs that carry the disparate NAS MAC and the disparate NAS uplink counter associated with the native security context A.

Network node1208can obtain the integrity protected mobility message with the optional IEs that carry the disparate NAS MAC and the disparate NAS uplink counter associated with the native security context A. Authentication component220can further include a request forward component502. Request forward component502can cause context fetch component222to forward the integrity protected mobility message with the optional IEs that carry the disparate NAS MAC and the disparate NAS uplink counter to network node2210for checking the integrity thereof.

Authentication component224of network node2210can further include a parameter exchange component504and integrity evaluation component406. Parameter exchange component504exchange parameters from the integrity protected mobility message with parameters carried by the optional IEs. For instance, parameter exchange component504can substitute the NAS MAC and the NAS uplink counter from the integrity protected mobility message corresponding to the mapped security context B-A (e.g., the NAS MAC yielded based upon a key from the mapped security context B-A, the NAS uplink counter associated with the mapped security context B-A, . . . ) with the disparate NAS MAC and the disparate NAS uplink counter associated with the native security context A carried by the optional IEs to yield a modified integrity protected mobility message. Moreover, integrity evaluation component406can check an integrity of the modified integrity protected mobility message utilizing the native security context A. However, it is also contemplated that integrity evaluation component406can check the integrity of the obtained integrity protected mobility message with the optional IEs without rearranging such message. If the integrity check by integrity evaluation component406is successful, then context forward component226can send the native security context A to network node1208. Alternatively, if the integrity check by integrity evaluation component406is unsuccessful, then a failure can be reported to network node1208and sending of the native security context A to network node1208can be inhibited.

System500and system400ofFIG. 4differ as to which network node modifies the integrity protected mobility message. In system400ofFIG. 4, network node1208can exchange parameters (e.g., substitute NAS MACs and NAS uplink counters with parameter exchange component404, . . . ) and then send the modified integrity protected mobility message to network node2210for the integrity check (e.g., with integrity evaluation component406, . . . ). In contrast, in system500, network node1208can transparently pass the integrity protected mobility message with the optional IEs that carry the additional parameters to network node2210(e.g., utilizing request forward component502, . . . ), and network node2210can substitute parameters (e.g., exchange NAS MACs and NAS uplink counters with parameter exchange component504, . . . ) and perform the integrity check (e.g., with integrity evaluation component406, . . . ).

With reference toFIG. 6, illustrated is a system600that enables a network node to perform an integrity check and fetch a security context in a wireless communication environment. Integrity protection component218can utilize the mapped security context B-A to integrity protect the mobility message yielded by area update component216. Further, the integrity protected mobility message can be sent (e.g., by area update component216, . . . ) from mobile device202to network node1208.

Network node1208can receive the integrity protected mobility message from mobile device202. Authentication component220can further include an integrity evaluation component602that can check an integrity of the integrity protected mobility message utilizing the mapped security context B-A. If the integrity check performed by integrity evaluation component602is successful, then context fetch component222can generate a context request message. Moreover, context fetch component222can include an identifier inclusion component604that can incorporate an identifier corresponding to mobile device202and an indication that mobile device202has been authenticated (e.g., by authentication component220, integrity evaluation component602, using the mapped security context B-A, the integrity check is successful, . . . ) in the context request message. For instance, the identifier provided in the context request message by identifier inclusion component604can be an International Mobile Subscriber Identity (IMSI). Further, context fetch component222can send the context request message with the identifier and the indication that mobile device202has been authenticated to network node2210. Alternatively, sending of the context request message can be inhibited if the integrity check performed by integrity evaluation component602is unsuccessful.

Authentication component224of network node2210can further include an identifier analysis component606that can evaluate the context request message received from network node1208. For instance, identifier analysis component606can recognize the identity of mobile device202based upon the identifier included in the context request message. Further, identifier analysis component606can detect that mobile device202has been successfully authenticated by network node1208. Further, context forward component226can send the native security context A for mobile device202to network node1208in response to the context request message. Context forward component226can transmit the native security context A as part of a context response message.

Now turning toFIG. 7, illustrated is a system700that utilizes a cached native security context to protect a mobility message after inter-system handover in a wireless communication environment. Integrity protection component218can further include a context selection component702that can choose a security context to leverage for protecting the mobility message yielded by area update component216. More particularly, after handover, context selection component702can select to utilize a cached native security context A (e.g., a cached native EPS security context, . . . ) to integrity protect the mobility message when mobile device202has the cached native security context A rather than utilizing the mapped security context B-A derived during handover. For example, mobile device202can temporarily have both mapped and native EPS security context activated, but can use the native EPS security context for the mobility message protection (e.g., TAU request message protection, . . . ). The integrity protected mobility message (e.g., integrity protected utilizing the native security context A, . . . ) can further be transmitted (e.g., by area update component216, . . . ) from mobile device202to network node1208.

Network node1208can receive the integrity protected mobility message from mobile device202. Authentication component220can include a request forward component704that can cause context fetch component222to forward the integrity protected mobility message to network node2210.

Authentication component224of network node2210can further include an integrity evaluation component706, which can check the integrity of the integrity protected mobility message utilizing the native security context A. If the integrity of the message is successfully verified by integrity evaluation component706, then context forward component226can send the native security context A to network node1208as part of a context response message; otherwise, if the integrity of the message is not successfully verified by integrity evaluation component706, then a failure can be reported to network node1208as part of the context response message.

Further, network node1208can include a context control component708that can manage a security context utilized by mobile device202(e.g., as chosen by context selection component702, . . . ) for subsequent messages. Context control component708can send a message to mobile device202indicating which security context (e.g., the native security context A, the mapped security context B-A, . . . ) to utilize for subsequent messages (e.g., subsequent NAS messages, . . . ) based upon the context response message received from network node2210. For example, context control component708and context selection component702can effectuate a Non-Access Stratum (NAS) Security Mode Command (SMC) procedure to change or maintain the security context leveraged by mobile device202for the subsequent messages.

Turning toFIG. 8, illustrated is a methodology800that facilitates obtaining a native security context from a disparate network node in a wireless communication environment. At802, a mobility message integrity protected by a security context can be received at a network node from a mobile device after an inter-system handover of the mobile device. The mobility message, for instance, can be a Tracking Area Update request message (TAU request message); however, the claimed subject matter is not so limited. Moreover, the network node can be a Mobility Management Entity (MME); yet, it is to be appreciated that the claimed subject matter is not so limited.

The mobility message can be integrity protected by a mapped security context derived from a differing native security context of a differing type of system (e.g., as compared to a type of system associated with the network node, . . . ) during the inter-system handover. For example, the mapped security context can be a mapped Evolved Packet System (EPS) security context derived from a native General Packet Radio Service (GPRS) security context utilized by the mobile device in a UMTS Terrestrial Radio Access Network (UTRAN) system or a GSM Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN) system prior to handover to an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) system. Moreover, the mobility message can be integrity protected by a native security context of a type of system associated with the network node, while the network node can lack the native security context when the mobility message is received. Thus, for example, the mobility message can be integrity protected by a native EPS security context, yet the network node can lack the native EPS security context for the mobile device when the mobility message is received.

At804, a request for a native security context can be sent to a disparate network node within a core network. The request can include information utilized by the disparate network node to ensure that the mobile device is authenticated. The disparate network node can be an MME and/or the core network can be an Evolved Packet System core network (EPS core network), for example; however, the claimed subject matter is not so limited. Further, the mobile device could have previously registered with the disparate network node to yield the native security context. Moreover, the native security context can be retained by the disparate network node when the mobile device moves to a disparate type of system (e.g., a UTRAN/GERAN system, . . . ). The native security context can be more secure than a mapped security context derived from a differing native security context of a differing type of system. Similarly, the native security context can be more secure than the differing native security context of the differing type of system. At806, the native security context can be received from the disparate network node in response to the request.

According to an example, the mobility message can be integrity protected (e.g., by the mobile device, . . . ) utilizing the mapped security context (e.g., the mapped EPS security context, derived from a differing native security context of a differing type of system, . . . ); thus, the mobility message can include a Non-Access Stratum (NAS) Message Authentication Code (MAC) and a NAS uplink counter associated with the mapped security context. Moreover, the mobility message can include optional information elements (IEs) that carry additional parameters generated based upon the native security context. The additional parameters can include a differing NAS MAC and a differing NAS uplink counter associated with the native security context. Further, parameters of the mobility message associated with the mapped security context can be replaced with the additional parameters associated with the native security context carried by the optional IEs to yield a modified mobility message. By way of illustration, the NAS MAC and the NAS uplink counter from the mobility message associated with the mapped security context can be replaced by the differing NAS MAC and the differing NAS uplink counter associated with the native security context carried by the optional IEs to yield the modified mobility message. Moreover, the request for the native security context can include the modified mobility message, which can be integrity checked by the disparate network node utilizing the native security context to authenticate the mobile device.

By way of another example, the mobility message can be integrity protected (e.g., by the mobile device, . . . ) employing the mapped security context (e.g., the mapped EPS security context, derived from a differing native security context of a differing type of system, . . . ); thus, the mobility message can include a NAS MAC and a NAS uplink counter associated with the mapped security context. Moreover, the mobility message can include optional IEs that carry additional parameters generated based upon the native security context. The additional parameters can include a differing NAS MAC and a differing NAS uplink counter associated with the native security context. Further, the mobility message integrity protected by the mapped security context that includes the optional IEs that carry the additional parameters (e.g., the differing NAS MAC and the differing NAS uplink counter associated with the native security context, . . . ) can be forwarded to the disparate network node. Thus, the request for the native security context can include the mobility message integrity protected by the mapped security context that includes the optional IEs that carry the additional parameters. Accordingly, the disparate network node can substitute parameters of the mobility message associated with the mapped security context with the additional parameters associated with the native security context carried by the optional IEs to yield a modified mobility message, which can be integrity checked by the disparate network node utilizing the native security context to authenticate the mobile device. Alternatively, it is contemplated that the disparate network node need not reorganize the mobility message integrity protected by the mapped security context that includes the optional IEs that carry the additional parameters to check the integrity.

Pursuant to another example, the mobility message can be integrity protected (e.g., by the mobile device, . . . ) utilizing the mapped security context (e.g., the mapped EPS security context, derived from a differing native security context of a differing type of system, . . . ). Further, an integrity check of the mobility message can be performed at the network node employing a mapped security context retained by the network node (e.g., derived during the inter-system handover, . . . ). If the integrity check is successful, then the request can be generated. The request can be a context request message that can include an identifier corresponding to the mobile device and an indication that the mobile device has been successfully authenticated by the network node. For example, the identifier corresponding to the mobile device can be an International Mobile Subscriber Identity (IMSI). Moreover, the context request message can be sent to the disparate network node, which can recognize the identity of the mobile device based upon the identifier and can detect that the mobile device has been successfully authenticated by the network node. Alternatively, if the integrity check is unsuccessful, then sending of the request can be inhibited.

By way of another example, the mobility message can be integrity protected (e.g., by the mobile device, . . . ) utilizing the native security context. Thus, the mobility message integrity protected utilizing the native security context can be sent to the disparate network node as part of the request. Hence, the mobility message can be integrity checked by the disparate network node utilizing the native security context to authenticate the mobile device. Further, a NAS Security Mode Command (SMC) procedure can be implemented to control (e.g., change or maintain, . . . ) the security context utilized by the mobile device for a subsequent message (e.g., subsequent NAS message, . . . ).

With reference toFIG. 9, illustrated is a methodology900that facilitates forwarding a native security to a disparate network node in a wireless communication environment. At902, a request for a native security context of a mobile device retained in memory of a network node can be received from a differing network node within a core network. The request can be responsive to a mobility message integrity protected by a security context from the mobile device after an inter-system handover of the mobile device. For instance, the network node and the differing network node can be Mobility Management Entities (MMES); however, the claimed subject matter is not so limited. Further, the mobility message, for instance, can be a Tracking Area Update (TAU) request message; yet, it is contemplated that the claimed subject matter is not so limited. Moreover, the core network can be an Evolved Packet System (EPS) core network, although, the hereto appended claims are not so limited.

The mobility message can be integrity protected by a mapped security context derived from a differing native security context of a differing type of system (e.g., as compared to a type of system associated with the network node, . . . ) during the inter-system handover. For example, the mapped security context can be a mapped EPS security context derived from a native General Packet Radio Service (GPRS) security context utilized by the mobile device in a UMTS Terrestrial Radio Access Network (UTRAN) system or a GSM Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN) system prior to handover to an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) system. Moreover, the mobility message can be integrity protected by a native security context of a type of system associated with the network node, while the differing network node can lack the native security context when the mobility message is received from the mobile device. Thus, for example, the mobility message can be integrity protected by a native EPS security context, yet the differing network node can lack the native EPS security context for the mobile device when the mobility message is received from the mobile device.

At904, the mobile device can be authenticated based at least in part upon information included in the request. At906, the native security context can be sent to the differing network node when the mobile device is authenticated. Alternatively, when the mobile device is unsuccessfully authenticated, then a failure can be reported to the differing network node and sending of the native security context can be inhibited.

For example, the request can include a modified mobility message, where parameters (e.g., a Non-Access Stratum (NAS) Message Authentication Code (MAC) and a NAS uplink counter, . . . ) of the mobility message associated with a mapped security context (e.g., utilized to integrity protect the mobility message, . . . ) are replaced with additional parameters associated with the native security context carried in optional information elements (IEs). Accordingly, the mobile device can be authenticated by checking an integrity of the modified mobility message using the native security context. If checking the integrity of the modified mobility message is successful, then the native security context can be sent to the differing network node. If checking the integrity of the modified mobility message is unsuccessful, then a failure can be reported to the differing network node and sending of the native security context can be inhibited.

According to another example, the request can include the mobility message integrity protected (e.g., by the mobile device, . . . ) utilizing the mapped security context that includes optional IEs that carry additional parameters (e.g., a differing NAS MAC and a differing NAS uplink counter associated with the native security context, . . . ). Further, parameters of the mobility message associated with the mapped security context can be replaced with the additional parameters associated with the native security context carried by the optional IEs to yield a modified mobility message. Moreover, the mobile device can be authenticated by checking an integrity of the modified mobility message using the native security context. If checking the integrity of the modified mobility message is successful, then the native security context can be sent to the differing network node. If checking the integrity of the modified mobility message is unsuccessful, then a failure can be reported to the differing network node and sending of the native security context can be inhibited. Alternatively, it is contemplated that the mobility message integrity protected by the mapped security context that includes the optional IEs that carry the additional parameters need not be reorganized to check the integrity.

By way of another example, the request can be a context request message that can include an identifier corresponding to the mobile device and an indication that the mobile device has been authenticated by the differing network node. For example, the identifier corresponding to the mobile device can be an International Mobile Subscriber Identity (IMSI). Thus, the mobile device can be authenticated by recognizing the identity of the mobile device based upon the identifier and detecting that the mobile device has been authenticated by the differing network node based upon the indication.

Pursuant to a further example, the request can include the mobility message integrity protected (e.g., by the mobile device, . . . ) utilizing the native security context. Accordingly, the mobile device can be authenticated by checking an integrity of the mobility message using the native security context. If checking the integrity of the mobility message is successful, then the native security context can be sent to the differing network node. If checking the integrity of the mobility message is unsuccessful, then a failure can be reported to the differing network node and sending of the native security context can be inhibited.

Now turning toFIG. 10, illustrated is a methodology1000that facilitates sending a mobility message after an inter-system handover in a wireless communication environment. At1002, a mobility message can be generated after an inter-system handover. For instance, the inter-system handover can be from a UMTS Terrestrial Radio Access Network (UTRAN) system or a GSM Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN) system to an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) system. Moreover, the mobility message can be a Tracking Area Update (TAU) request message; yet, it is contemplated that the claimed subject matter is not so limited.

At1004, an integrity of the mobility message can be protected utilizing a security context to yield an integrity protected mobility message. The integrity of the mobility message can be protected by a mapped security context derived from a native security context of a type of system from which a mobile device is handing over. For example, the mapped security context can be a mapped Evolved Packet System (EPS) security context derived from a native General Packet Radio Service (GPRS) security context utilized in a UTRAN system or a GERAN system prior to handover to an E-UTRAN system. Moreover, the mobility message can be integrity protected by a native security context of a type of system to which the mobile device hands over. Thus, for example, the mobility message can be integrity protected by a native EPS security context.

At1006, the integrity protected mobility message can be transmitted intended for a network node in a core network. The integrity protected mobility message can be utilized by the network node to fetch a native security context from a disparate network node.

According to an example, the integrity of the mobility message can be protected utilizing the mapped security context (e.g., the mapped EPS security context, derived from a differing native security context of a differing type of system, . . . ); thus, the mobility message can include a Non-Access Stratum (NAS) Message Authentication Code (MAC) and a NAS uplink counter associated with the mapped security context. Moreover, additional parameters can be generated based upon the native security context, and the additional parameters can be carried in optional information elements (IEs) of the integrity protected mobility message. The additional parameters can include a differing NAS MAC and a differing NAS uplink counter associated with the native security context.

By way of another example, the integrity of the mobility message can be protected utilizing the native security context. Moreover, the security context to be utilized for a subsequent message (e.g., subsequent NAS message, . . . ) can be controlled by the network node by implementing a NAS Security Mode Command (SMC) procedure.

FIG. 11is an illustration of a mobile device1100that sends a mobility message in a wireless communication system. Mobile device1100comprises a receiver1102that receives a signal from, for instance, a receive antenna (not shown), and performs typical actions thereon (e.g., filters, amplifies, downconverts, etc.) the received signal and digitizes the conditioned signal to obtain samples. Receiver1102can be, for example, an MMSE receiver, and can comprise a demodulator1104that can demodulate received symbols and provide them to a processor1106for channel estimation. Processor1106can be a processor dedicated to analyzing information received by receiver1102and/or generating information for transmission by a transmitter1116, a processor that controls one or more components of mobile device1100, and/or a processor that both analyzes information received by receiver1102, generates information for transmission by transmitter1116, and controls one or more components of mobile device1100.

Mobile device1100can additionally comprise memory1108that is operatively coupled to processor1106and that can store data to be transmitted, received data, and any other suitable information related to performing the various actions and functions set forth herein. Memory1108, for instance, can store protocols and/or algorithms associated with generating a mobility message, integrity protecting a mobility message, and so forth. Moreover, memory1108can include one or more security contexts associated with mobile device1108.

Processor1106can be operatively coupled to an area update component1110and/or an integrity protection component1112. Area update component1110can be substantially similar to area update component216ofFIG. 2and/or integrity protection component1112can be substantially similar to integrity protection component218ofFIG. 2. Area update component1110can generate a mobility message after an inter-system handover. Moreover, integrity protection component1112can protect an integrity of the mobility message using a security context to yield an integrity protected mobility message. Thereafter, the integrity protected mobility message can be transmitted (e.g., by transmitter1116, area update component1110, . . . ) to a network node in a core network (e.g., via a base station, . . . ). Moreover, although not shown, it is contemplated that mobile device1100can further include a parameter inclusion component (e.g., substantially similar to parameter inclusion component402ofFIG. 4, . . . ) and/or a context selection component (e.g., substantially similar to context selection component702ofFIG. 7, . . . ). Mobile device1100still further comprises a modulator1114and a transmitter1116that transmits data, signals, etc. to a base station. Although depicted as being separate from the processor1106, it is to be appreciated that area update component1110, integrity protection component1112and/or modulator1114can be part of processor1106or a number of processors (not shown).

FIG. 12is an illustration of a system1200that operates in a wireless communication environment. System1200comprises a base station1202(e.g., access point, . . . ) with a receiver1210that receives signal(s) from one or more mobile devices1204through a plurality of receive antennas1206, and a transmitter1220that transmits to the one or more mobile devices1204through a transmit antenna1208. Moreover, base station1202can receive signal(s) with receiver1210from one or more disparate base stations through the plurality of receive antennas1206and/or transmit to one or more disparate base stations with transmitter1220through the transmit antenna1208. According to another illustration, base station1202can receive signal(s) from (e.g., with receiver1210, . . . ) and/or transmit signal(s) to (e.g., with transmitter1220, . . . ) one or more disparate base stations via a backhaul. Receiver1210can receive information from receive antennas1206and is operatively associated with a demodulator1212that demodulates received information. Demodulated symbols are analyzed by a processor1214that can be similar to the processor described above with regard toFIG. 11, and which is coupled to a memory1216that stores data to be transmitted to or received from mobile device(s)1204and/or disparate base station(s) and/or any other suitable information related to performing the various actions and functions set forth herein. Base station1202can further include a modulator1218. Modulator1218can multiplex a frame for transmission by a transmitter1220through antennas1208to mobile device(s)1204in accordance with the aforementioned description. Although depicted as being separate from the processor1214, it is to be appreciated that modulator1218can be part of processor1214or a number of processors (not shown).

FIG. 13shows an example wireless communication system1300. The wireless communication system1300depicts one base station1310and one mobile device1350for sake of brevity. However, it is to be appreciated that system1300can include more than one base station and/or more than one mobile device, wherein additional base stations and/or mobile devices can be substantially similar or different from example base station1310and mobile device1350described below. In addition, it is to be appreciated that base station1310and/or mobile device1350can employ the systems (FIGS. 1-7,11-12and14-16) and/or methods (FIGS. 8-10) described herein to facilitate wireless communication there between.

At base station1310, traffic data for a number of data streams is provided from a data source1312to a transmit (TX) data processor1314. According to an example, each data stream can be transmitted over a respective antenna. TX data processor1314formats, codes, and interleaves the traffic data stream based on a particular coding scheme selected for that data stream to provide coded data.

The modulation symbols for the data streams can be provided to a TX MIMO processor1320, which can further process the modulation symbols (e.g., for OFDM). TX MIMO processor1320then provides NTmodulation symbol streams to NTtransmitters (TMTR)1322athrough1322t. In various embodiments, TX MIMO processor1320applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Each transmitter1322receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. Further, NTmodulated signals from transmitters1322athrough1322tare transmitted from NTantennas1324athrough1324t, respectively.

At mobile device1350, the transmitted modulated signals are received by NRantennas1352athrough1352rand the received signal from each antenna1352is provided to a respective receiver (RCVR)1354athrough1354r. Each receiver1354conditions (e.g., filters, amplifies, and downconverts) a respective signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding “received” symbol stream.

An RX data processor1360can receive and process the NRreceived symbol streams from NRreceivers1354based on a particular receiver processing technique to provide NT“detected” symbol streams. RX data processor1360can demodulate, deinterleave, and decode each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor1360is complementary to that performed by TX MIMO processor1320and TX data processor1314at base station1310.

A processor1370can periodically determine which precoding matrix to utilize as discussed above. Further, processor1370can formulate a reverse link message comprising a matrix index portion and a rank value portion.

The reverse link message can comprise various types of information regarding the communication link and/or the received data stream. The reverse link message can be processed by a TX data processor1338, which also receives traffic data for a number of data streams from a data source1336, modulated by a modulator1380, conditioned by transmitters1354athrough1354r, and transmitted back to base station1310.

At base station1310, the modulated signals from mobile device1350are received by antennas1324, conditioned by receivers1322, demodulated by a demodulator1340, and processed by a RX data processor1342to extract the reverse link message transmitted by mobile device1350. Further, processor1330can process the extracted message to determine which precoding matrix to use for determining the beamforming weights.

Processors1330and1370can direct (e.g., control, coordinate, manage, etc.) operation at base station1310and mobile device1350, respectively. Respective processors1330and1370can be associated with memory1332and1372that store program codes and data. Processors1330and1370can also perform computations to derive frequency and impulse response estimates for the uplink and downlink, respectively.

It is to be understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the processing units can 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, other electronic units designed to perform the functions described herein, or a combination thereof.

With reference toFIG. 14, illustrated is a system1400that enables collecting a native security context in a wireless communication environment. For example, system1400can reside at least partially within a network node of a core network. For instance, the network node can be an MME and the core network can be an EPS core network; yet, the claimed subject matter is not so limited. It is to be appreciated that system1400is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware). System1400includes a logical grouping1402of electrical components that can act in conjunction. For instance, logical grouping1402can include an electrical component for obtaining a mobility message integrity protected by a security context from a mobile device after an inter-system handover of the mobile device1404. Further, logical grouping1402can include an electrical component for fetching a native security context from a disparate network node within a core network utilizing a request that includes information employed by the disparate network node to establish that the mobile device is authenticated1406. Logical grouping1402can also optionally include an electrical component for exchanging parameters of the mobility message with parameters carried by optional information elements (IEs) of the mobility message1408. For instance, a NAS MAC and a NAS uplink counter can be exchanged. Moreover, logical grouping1402can optionally include an electrical component for evaluating an integrity of the mobility message utilizing a mapped security context1410. By way of example, the mobility message can be integrity protected by the mobile device employing the mapped security context. Further, the request can include an identifier corresponding to the mobile device and an indication that the integrity of the mobility message has been successfully verified. Logical grouping1402can also optionally include an electrical component for controlling the security context utilized by the mobile device for a subsequent message1412. Additionally, system1400can include a memory1414that retains instructions for executing functions associated with electrical components1404,1406,1408,1410, and1412. While shown as being external to memory1414, it is to be understood that one or more of electrical components1404,1406,1408,1410, and1412can exist within memory1414.

With reference toFIG. 15, illustrated is a system1500that enables providing a native security context in a wireless communication environment. For example, system1500can reside at least partially within a network node of a core network. For instance, the network node can be an MME and the core network can be an EPS core network; yet, the claimed subject matter is not so limited. It is to be appreciated that system1500is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware). System1500includes a logical grouping1502of electrical components that can act in conjunction. For instance, logical grouping1502can include an electrical component for obtaining a request for a native security context of a mobile device from a differing network node within a core network1504. Further, logical grouping1502can include an electrical component for authenticating the mobile device based at least in part upon information included in the request1506. Moreover, logical grouping1502can include an electrical component for transmitting the native security context to the differing network node when the mobile device is authenticated1508. Logical grouping1502can also optionally include an electrical component for evaluating an integrity of a mobility message included with the request utilizing the native security context1510. Additionally, logical grouping1502can optionally include an electrical component for exchanging parameters of the mobility message with parameters carried by optional information elements (IEs) of the mobility message1512. Additionally, system1500can include a memory1514that retains instructions for executing functions associated with electrical components1504,1506,1508,1510, and1512. While shown as being external to memory1514, it is to be understood that one or more of electrical components1504,1506,1508,1510, and1512can exist within memory1514.

With reference toFIG. 16, illustrated is a system1600that enables yielding a mobility message in a wireless communication environment. For example, system1600can reside within a mobile device. It is to be appreciated that system1600is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware). System1600includes a logical grouping1602of electrical components that can act in conjunction. For instance, logical grouping1602can include an electrical component for yielding a mobility message after an inter-system handover1604. Further, logical grouping1602can include an electrical component for protecting an integrity of the mobility message employing a security context to generate an integrity protected mobility message1606. Moreover, logical grouping1602can include an electrical component for transmitting the integrity protected mobility message1608. The integrity protected mobility message can be utilized by a network node to fetch a native security context from a disparate network node in a core network. Logical grouping1602can also optionally include an electrical component for including parameters associated with the native security context in optional information elements (IEs) of the integrity protected mobility message1610. Additionally, system1600can include a memory1612that retains instructions for executing functions associated with electrical components1604,1606,1608, and1610. While shown as being external to memory1612, it is to be understood that one or more of electrical components1604,1606,1608, and1610can exist within memory1612.

Further, the steps and/or actions of a method or algorithm described in connection with the aspects disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium can be coupled to the processor, such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. Further, in some aspects, the processor and the storage medium can reside in an ASIC. Additionally, the ASIC can reside in a user terminal In the alternative, the processor and the storage medium can reside as discrete components in a user terminal Additionally, in some aspects, the steps and/or actions of a method or algorithm can reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer readable medium, which can be incorporated into a computer program product.

While the foregoing disclosure discusses illustrative aspects and/or embodiments, it should be noted that various changes and modifications could be made herein without departing from the scope of the described aspects and/or embodiments as defined by the appended claims. Furthermore, although elements of the described aspects and/or embodiments can be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, all or a portion of any aspect and/or embodiment can be utilized with all or a portion of any other aspect and/or embodiment, unless stated otherwise.