CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U. S. Provisional Patent Application No.

62/205,194, filed August 14, 2015, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Machine to Machine (M2M) and/or Internet of Things (IoT) may be an Internet paradigm that may be used to remotely configure and control a very large amount of electronic equipment (e.g., M2M and/or IoT units or devices) and may open up additional possibilities with respect to services such as automotive, industry control, traffic management and building automation, may reduce cost for maintenance, surveillance, production, transport and communications, and/or the like. In such M2M and/or IoT systems, networks, and/or units or devices, upgrades (e.g., to the software) may be provided to add functionality and/or improve security and/or compatibility. Unfortunately, such an upgrade may be susceptible to attacks including hacking and/or installation of malicious code.

SUMMARY

[0003] Systems, methods, and/or devices for upgrading an IoT device or unit may be provided. For example, a device, such as an IoT device or unit, may receive an indication or notification that an upgrade may be available, e.g., from a network device such as a device management server (DMS). The IoT device or unit may establish a secure connection with the network device. The IoT device or unit may receive, e.g., via the secure connection, an integrity protection key, a first hash value, and an indication of a number of portions associated with the upgrade; The IoT device or unit may receive (e.g., download) a plurality of portions of the upgrade. For each of the plurality of portions, the IoT device or unit may verify a message authentication code (MAC) associated with the respective portion, e.g., that a MAC calculated for the respective portion matches a received MAC received in the respective portion. For each of the plurality of portions, the IoT device or unit may verify that a time for validity of the upgrade may not exceed a validity time or threshold. In the present example, responsive to a determination that each of the portions may be verified based on the MAC associated with the portion, the IoT unit may further verify the portions of the upgrade package by, for example, verifying a first portion of the plurality of portions of the upgrade using a first hash value, determining or extracting a next hash value from the verified first portion of the upgrade, and/or verifying a subsequent or next portion using the next hash value. The IoT device or unit, for example, responsive to a determination that the each of the portions (e.g., the first portion and the second portion) may be verified based on the respective hash values may then perform the upgrade.

[0004] The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, not is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to the examples herein that may solve one or more disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding of the embodiments disclosed herein may be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0006] FIG. 1 illustrates an example IoT and/or M2M network that may be used to provide protected software delivery according to one or more examples herein.

[0007] FIG. 2 illustrates an example of protected software delivery according to one or more of the examples herein.

[0008] FIG. 3 illustrates an example IoT and/or M2M network and flow that may be used to provide protected software delivery according to one or more examples herein.

[0009] FIG. 4 illustrates an example for providing software delivery and/or improving software delivery as described in examples herein.

[0010] FIG. 5 illustrates an example package format that may be used according to one or more examples herein.

[001 1] FIG. 6 illustrates an example, e.g., at a server, for providing software delivery and/or improving software delivery as described in examples herein. [0012] FIGs. 7-8 illustrate examples, at an IoT device or unit, for providing software delivery and/or improving software delivery and/or installing such software as described in examples herein.

[0013] FIGs. 9A and 9B illustrate an example of a system in which one or more examples described herein may be used and/or implemented.

[0014] FIG. 10A depicts a diagram of an example communications system in which one or more disclosed examples may be implemented and/or may be used with one or more of the examples described herein.

[0015] FIG. 10B depicts a system diagram of an example device such as a wireless transmit/receive unit (WTRU), server, database, and/or the like that may be used within the communications system illustrated in FIG. 10A.

[0016] FIG. IOC depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 10A.

[0017] FIG. 10D depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 10A.

[0018] FIG. 10E depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 10A.

DETAILED DESCRIPTION

[0019] A detailed description of illustrative embodiments may now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the examples described herein. In addition, the figures may illustrate mechanisms, which are meant to be exemplary. Other embodiments may be used. The order of the features in the mechanism(s) may be varied where appropriate. Features may be omitted if not needed, and, additional features may be added.

[0020] Systems, methods, and devices may be provided for secure and efficient software

(SW) upgrades on resource constrained devices, such as Machine-to-Machine (M2M) or Internet-of-Things (IoT) devices or units. One one or more implementations herein may be robust against DoS attacks. In examples, the systems, methods, and/or devices may include principles for secure SW upgrades that may not be dependent on public key capabilities on the resource constrained device (e.g., the IoT unit or device and/or the M2M unit or device) and may instead use symmetric key capabilities and, for example, may be made over a connection-less transport such as CoAP.

[0021] As described herein, M2M or IoT systems may be starting to become more widely deployed. FIG. 1 illustrates an example of a M2M and/or IoT network 200. As shown in FIG. 1, such a system or network may include distributed units such as IoT units 202a-h.

According to examples herein, M2M and/or IoT units may be referred to as IoT units or devices (e.g., which may include M2M units or device, IoT units or devices, and/or other similar devices or units) and may be a device that may include components such as those described with respect to the devices or WTRUs 102a-d in FIGs. 10A-10E. In an example, as shown in FIG. 1, the IoT units 202a-h may be a set of wireless battery driven devices. For example, in one or more examples described herein, the IoT units 202a-h may be one or more resource constrained devices with respect to computing capabilities, volatile and non-volatile memory capabilities, and/or the like. The IoT units 202a-h may be communicated with and/or controlled (e.g., directly) by a device or back-end server which may include devices (e.g., which may include any suitable computer, device, server, database, node, and/or the like) such as a Device Management Server (DMS) 208. In examples, the DMS 208 may belong to an owner organization (e.g., that may deploy and/or control the IoT units). As shown, a cloud server 207 may also be included in the network and may communicate with the IoT units 202a-h and/or the DMS 208 in examples herein.

[0022] As shown in FIG. 1 (e.g., to provide communication between the devices (e.g.,

202a-h) in the network 200 and/or to enable control by the DMS 208), the IoT units 202a-h may be connected to the DMS 208 via one or more network technologies. For example, the IoT units

202a-h and/or the DMS 208 may have general Internet connectivity (e.g., to the Internet 205).

The access thereto may be of different types including, but not limited to, cellular access, WLAN access, fixed broadband access or corporate network access, and/or the like. For example, as shown in FIG. 1, the IoT units 202a-b may be connected to a cellular network 209 such as 3G,

4G, 5G, LTE, E-UTRAN, and/or the like (e.g., that may described with respect to FIGs. 10A-

10E below) that may provide access to the Internet 205. The IoT units 202c-202d and/or 202g-h may be connected to a LAN and/or a WAN 206 that may provide access to the Internet 205. As shown, in one example, a local sever 210 may be provided (e.g., that may enable access and/or control) that may be in communication with the DMS 208 via the Internet 205. The local server

210 may have and/or provide access and/or communication to the Internet 205 for the IoT units

202c-d and/or the DMS 208. The IoT units 202e-202f may be connected to and/or included in an IoT wireless domain 212. The IoT wireless domain 212 may provide Internet connectivity to the IoT devices 202e-f and/or provide communication to the back-end system such as DMS 208 (e.g., using the LANAVLAN 206). Such IoT devices 202e-f may also have access and/or may be connected to the local server 210. The DMS 208 may be connected to the Internet 205 via a private network and/or other network technologies such as network 213 such that the DMS 208 may control the IoT units 202a-h and/or may connect to the cloud server 207 and/or the local server 210.

[0023] In FIG. 1, software and/or firmware that may be associated with the IoT units

202a-h may be upgraded and/or updated (e.g., to fix bugs, improve functionality, add functionality, and/or the like). An update, e.g., an upgrade image (e.g., software (SW) upgrade image and/or firmware (FW) upgrade image), may be provided and/or sent (e.g., securely and/or efficiently as described herein) to one or more of the IoT units in the network or system. The upgrade image may be the same that may be distributed to the IoT units (e.g. in other examples it may be different). To distribute the image to the IoT units (e.g., 202a-h) or resource constrained devices, the image may be divided into a sequence of upgrade pieces (e.g., portions). For example, the image may be divided in I pieces such that the complete image may be defined as / = {I0J1J2,... Jn-i}, where h denote the z-th SW segment in the sequence of the upgrade pieces or segments.

[0024] The techniques of distribution of the image may be flexible and may include one or more of the following. For example, the distribution may include multicast directly by the DMS (e.g., 208) of the upgrade pieces or segments using suitable multicast technologies. This may be shown in FIG. lfor the distribution of the image to the IoT units 202a-b that may be (e.g., directly) connected to the cellular network 209.

[0025] In an example, the distribution may include distribution by the DMS of the image

(e.g., the whole image) such as the image /to a suitable cloud server such as the cloud server 207. The IoT units (e.g., one or more of 202a-h) may be informed by the DMS 208 where to find the image such that the IoT units may download (e.g., directly download) the image and/or the packages or pieces thereof in the image from this cloud server. This may be shown FIG. 1 where the LANAVLAN 212 that may provide connectivity to the IoT units 202g-h may use this image download option.

[0026] The distribution may include the distribution of the image (e.g., the whole image) such as the image /to a local server in a local LAN that may be located (e.g., geographically) closer the IoT units subject to the upgrade. In such an example, the IoT units may be informed by the DMS 208 where to find the image locally such that the IoT units may (e.g., directly) download the different SW packages or pieces in the image from the local server. This may be shown in FIG. 1 where the LAN/WLAN 206 and wireless IoT domain 211 connected IoT units 202c-f, respectively, may use this image download technique (e.g., may download the image from the local server 210 as described herein). This may save bandwidth over a potentially constrained network link connecting the local domain to the Internet 205 as not each one of the IoT units may need to request the upgrade packets over the narrow link.

[0027] In examples herein, the distribution may include unicast distribution by the DMS

208 of / to a local server that then multicasts or broadcasts the packets to a local network domain. The distribution may further include (e.g., direct) download of / from the DMS 208 by the different IoT units (e.g., 202a-h).

[0028] As described herein, one or more techniques for updating resource constrained wireless devices (e.g., a sensor node) may include a bandwidth effective, secure, public key based secure SW upgrade. FIG. 2 illustrates an example that may be used in such a bandwidth effective, secure, public key based secure SW upgrade. The image may be divided into n distinct upgrade packages. Each package may be integrity protected using a secure one-way hash chain as shown in FIG. 2. The first hash value as shown in FIG. 2 may be digitally signed by the authorized SW distributor and the wireless sensor node or device may have access to the public key of the authorized SW distributor such that this first signature may be verified by the sensor node. This may enable or allow the sensor nodes (e.g., when each of the pieces or packets arrives in order) to efficiently verify the integrity of the complete SW upgrade.

[0029] Denial of Service (DoS) attacks (e.g., an attack by a hacker and/or hostile organization that may compromise and/or may attack the battery and/or other components of the

IoT units) and/or out of order packet (e.g., portion) delivery may pose additional issues. The technique may use a hash-tree based approach, for example, where the image may be divided into a tree structure and similar hash tree structure and the "root node" (e.g., only the root node) of this tree may be digitally signed. In such an example, the image distribution may be verified as long as each of the packages in one level of the tree may be received (e.g., although the packages in that one level may be received out of order) before the packages in the next level may be verified. This may improve DoS resistance and robustness with respect to package delivery. Such a hash tree approach may complicate the distribution of the image and/or the verification on the sensor side or device side and may not be compatible with every SW delivery technique. A message authentication code technique may be added.

[0030] In an example, a method for updating or upgrading SW may include a pure symmetric key based approach. A message authentication code (MAC) based on a common symmetric key may be used for devices subject to upgrade in the system, e.g., in combination with a bloom-filter. According to an example, a MAC (e.g., one MAC) may be used to protect the Bloom filter itself and another MAC (e.g., a second one) to verify the image (e.g., the whole SW image). This may enable or allow checking of individual SW packages (e.g., checking Bloom filter membership) even if the packages may arrive out of order. Bloom filters may provide and/or give false positive answers which may not be acceptable under some

circumstances. For example, this might not be acceptable in systems where a correct transmitted SW package may be accepted after transmission without the need for retransmissions, e.g., as long as the system may not be under attack, retransmission may not occur. The overall security level may not be high as the SW may be protected with a MAC key common to each of the devices in the system subject to the upgrade.

[0031] A technique for updating or upgrading SW may include combining the use of one-way hash chain protection of the SW updated packages with verification of each SW upgrade package using a MAC (e.g., combining the techniques). The keys used to calculate this MAC may be calculated by the SW distributor node and may be openly disclosed to the whole network with delay (e.g., in time). This may be similar to some of the examples herein that may include a combination of the approach of using hash values with MAC protection of individual SW upgrade packages. One or more of the examples described herein may include a key derivation approach for the calculation of the MAC values as well as for the protection of the initial hash value in the hash chain. The one or more examples herein may not be limited to a broadcast/multicast setting.

[0032] Techniques for upgrading and/or updating SW may include delegation of the SW upgrade rights to several nodes in the system (e.g., not a single distributor).

[0033] Implementations herein may be provided for secure SW upgrade or update of a large set of units (e.g., IoT units) or resource constrained units that may not be limited to a broadcast or distribution, may be less susceptible to DoS attacks, may not need packets or pieces to be received in order, and/or may be secure and/or efficient. For example, one or more of the exampes herein may provide one or more of the following: they may work over unreliable transport, they may not be dependent on public key operation on the IoT side, they may be robust against DoS attacks during the SW upgrade, they may be efficient with respect to memory and bandwidth requirements, they may be flexible with respect to SW distribution mechanism, e.g., cover local download, remote download or multicast delivery.

[0034] The IoT units may be configured to install verified upgrades, specifically encrypted for the particular device, within a limited time period after notification that the upgrade is available. To enable such an install, for example, each upgrade segment (e.g., software upgrade segment or piece) may be transmitted or sent with a segment-specific MAC and the hash value for verifying the next segment as described herein.

[0035] FIG. 3 illustrates an example IoT and/or M2M network (e.g., system 200) that may be used to provide protected software delivery and upgrade according to one or more examples herein. One or more of the features described may be used. As shown, at 1, a network device such as the DMS 208 may notify the IoT units (e.g., such as 202f) in the system that an image (e.g., a new SW image, e.g., an upgrade) may be available for download. According to an example, before the IoT units may be able to download or receive this image, each unit may setup (or be contacted by the DMS for) a secure configuration session with the DMS. During this session, the DMS may transfer information (e.g., one or more of the following), for example, to the IoT unit: a system wide secret key material that may be used by the IoT units subject to the upgrade to verify the integrity and may be used to decrypt the SW information in the upgrade, timing information, T, that may be used to indicate and/or be used to determine how long the image may be valid for download, an image one-way hash root value, ho, a number of packages in the distribution of the image or the software (e.g., this may be denoted by n), and/or the like. The key material may be used to verify the MACs that may be sent as part of the transfers (e.g., at 3 below) according to an example.

[0036] At 2 (e.g., as shown for 202f), in an example such as after exchanging the information at 1, each IoT unit may start an internal clock, t = 0. For example, each IoT unit may have a clock that may be used to track the length of validity of the image for upgrade and/or update. The clock may be set and started at 2 and may be used as described herein in one or more examples.

[0037] At 3 (e.g., using any suitable SW distribution feature described herein, for example above), each IoT unit (e.g., 202f as shown in this example) that may be subject to upgrade may download or may receive the image (e.g., the new SW image) in the form of n different pieces or packages (e.g., portions). In the example shown in FIG. 3 the portions may be downloaded and/or received from the cloud server 207, e.g., as described in one of the distribution examples above. The different SW packages (e.g., portions) may be delivered in order and/or may be received in mixed order. For each received SW package, at 3, the IoT unit may perform one or more of the following. If t > T (e.g., where T may be the time associated with the validity of the package), the SW upgrade may be aborted and no additional SW packages may be received and/or accepted by the IoT unit. For each received package at 3 (e.g., and when the t < T), the integrity of the SW package may be checked, e.g., using the key received at 1 (e.g., the MAC received at 3 may be checked using the key material received at 1). If the check is successful (e.g., if the MAC calculated by the IoT unit using the key received at 1 coincides with the MAC of the SW package), the package may be stored in the IoT unit (e.g., the internal non-volatile memory). It may be marked as "non-valid" (e.g., and may remain that way until further verification using a hash as described herein). If the check fails, the SW package may be rejected.

[0038] According to an example, at 4 (e.g., if/when the IoT unit may have received and successfully verified a package (e.g., the first package) in the image or sequence of SW upgrade packages,) the following may be performed and/or applied to further verify the image and/or packages associated therewith. The IoT unit may set i = 0 (e.g., where i may be the package index and may equal zero for the first package of the sequence of packages (e.g., portions) that may make up the image). The IoT unit may verify SW package i using fa and if the verification is successful (e.g., where successful verification may include the hash of the first SW package coinciding with the ho, e.g., the hash root value, for the SW distribution which may be sent and received at 1 to the IoT unit over a secure channel as described herein) and (e.g., if successful) may mark SW package i as valid and extract fa+i from the SW package. The IoT, at 4, may decrypt the SW image piece from the package that may be valid and may store it therein (e.g., in memory). The IoT unit (e.g., at 4) may set i = i +1, if i< n, and may verify a subsequent SW package (e.g., portion) that may be received and (e.g., if verified) may mark it as valid and/or extract the hash from the package, decrypt the image and store it there (e.g., this may be performed in a loop until i > n ) otherwise the method may be aborted. In examples herein, 4 may be performed when each of the packages may be verified and received according to 3 or may be interleaved with 3, e.g., as soon as enough packages (e.g., all portions) have been verified and received, the final verification of the image according to 4 may start.

[0039] In an example, if each of n SW packages is successfully verified at 4, the IoT unit may perform the SW upgrade associated with the SW distribution. For example, the IoT unit may install the image from the packages or pieces at 5 based on the verification at 4.

[0040] At 6, the SW upgrade packages may be wiped out from IoT memory (e.g., after installation at 5). For example, at 6, the IoT unit may delete the image or packages or pieces thereof from its memory.

[0041] FIG. 4 illustrates an example upgrade 300 for providing software delivery and/or improving software delivery for upgrading as described herein. Upgrade 300 may include one or more of the following features. Upgrade 300 may be the flow and/or similar to the flow of FIG.

3 and/or may be performed by the components as described therein. For example, as shown as part of 1, the DMS 208 may provide the information to the IoT unit (e.g., or node) (e.g., that there are three packages, e.g., portion, to the upgrade). The IoT unit may start the timer (e.g., as described herein), e.g., as part of 2. The distribution server that may include the packages for the image (e.g., the cloud server 207 as shown in FIG. 3 in one example) may provide a package or piece 0 of the image and a MAC associated therewith to the IoT unit that may receive it and/or download it as part of 3. The package or piece 0 (e.g., portion 0) may be verified with its associated MAC (e.g., MACo) (e.g., verified with the key material to determine to determine whether the MACs coincide as described herein). As shown, the package or piece 2 may then be received at 3 and verified similar to package or piece 0 using its associated MAC (e.g., MAC2), and may be verified with the key material to determine to determine whether the MACs coincide as described herein. Package or piece 1 may be subsequently received as part of 3, and may be verified similar to package or piece 0 and 2 using its associated MAC (e.g., MACi). In an example, the IoT unit may then verify package or piece 0 with the hash ho received in the information as part of 1 and may extract the hash for package or piece 1 (e.g., hi) therefrom. The IoT unit may then verify package or piece 1 and extract the hash for package or piece 2 (e.g., hi) as described herein as part of 4. In an example (e.g., after the verification at 4), the IoT may upgrade or update itself with the image by combining the pieces or packages (e.g., portions) 0, 1, and 2 as described herein.

[0042] FIG. 5 illustrates an example package format 400 that may be used according to one or more examples herein. As shown, each package (e.g., portion) associated with an image may include an index, a software block for that package or piece, a hash value and/or a value (e.g., to calculate the hash of a subsequent package as described herein based on the previous hash or in the instance of the first piece or package the previous has being the first hash (e.g. ho) received from the DMS as part of the information provided thereby), and/or the MAC for the respective piece or package. The IoT units may use one or more parts of this format as described herein to verify each package and/or subsequently combine and install them (e.g., if successfully verified).

[0043] According to one or more examples herein, the example implementations or parts thereof described in FIGs. 3 and 4 may include additional feature(s) that may be performed by the DMS and/or the IoT to upgrade and/or update IoT unit(s) (e.g., 202a-h) as described herein.

These may be illustrated in more detail in FIGs. 6-8. In such examples, a set of IoT units (e.g.,

202a-h) in the network or system that may be subject to an upgrade (e.g., a SW upgrade) may be denoted by U. Further, the SW upgrade information (e.g., the complete upgrade software image) may be denoted by / = I0 1J2, ... ,In-i, e.g., the SW upgrade information may be split into n different distinct pieces (e.g., portions). According to an example, the image may be distributed using a sequence of SW package. This sequence of upgrade packages may be denoted by: P = Po, Pi, P2, ... ,Pn-i. These upgrade packages may include the SW image portions, /, and may include additional information. For each IoT unit (e.g., Vu E U), K _u , may be provided as a shared long-term secret shared between the respective IoT unit u and the DMS. In one or more examples herein, a time parameter set by the DMS (e.g., and provided by the DMS) that may indicate a validity period for P may be defined as T. fa may represent or define a one-way secure hash of the upgrade package Pi, e.g.,fa = H(P _; ). An integrity protection key that may be used by the DMS to integrity protect the different SW upgrade packages may be denoted by IKsw and/or a confidentiality protection key that may be used by the DMS to encrypt the SW packages prior to distribution may be denoted by Ksw. Each SW package may be integrity protected using a message authentication code (MAC), which may be denoted for ; by MACi.

[0044] Before the SW distribution is performed, according to an example, the DMS may package the SW distribution into SW packages (e.g., portions), for example of suitable sizes. According to examples herein, the SW packages may be integrity and/or confidentiality protected. The purpose of this protection may be to make it harder for an attacker to perform a DoS attack on the upgrade process as described herein.

[0045] FIG. 6 illustrates an example implementation 500, e.g., at a server or a DMS (e.g.,

208), for providing such packages (e.g., generating such packages for improving software delivery and/or an upgrade) as described in examples herein. One or more of the features in FIG. 6 may be performed. As shown in FIG. 6, at 1, a DMS (e.g., 208) may generate two random symmetric keys, IKsw, and Ksw and, at 2, the DMS may split the SW update image into n distinct parts: Io,Ii,h,. . . ,In-i.

[0046] In examples herein, the DMS may calculate n different SW upgrade packages: Pi =

{i, E(Ksw ,I,) i,MAd}, 0≤ i < n-2, P _n -i = {n-1, E(Ksw, In-i), MACn-i} , where E(Ksw , ) denotes encryption using a suitable symmetric encryption scheme under the key Ksw. This encrypted structure may also include a suitable Initialization Vector (IV). In such an example, fa =

H({i,E(Ksw , ), fa+i},0< i < n-2, and h _n -i = H({n-l,E(Ksw ,In-i)} where H may be a suitable, secure one-way hash function such as SHA-2, SHA-3, and/or the like, and/or MACi =

MAC(IKsw, {i, E(Ksw J,),fa+i}), 0≤ i < n-2, and MACn-i = MAC(IKsw, {n-1, E(Ksw /«-;),} where MAC may denote a suitable message authentication code function under the integrity protection key, IKsw, such as HMAC, a short MAC, and/or the like.

[0047] At 4, the DMS may determine and/or select the distribution technique for the image. For example, as described herein, the DMS may use different methods for the distribution of /. The SW packages may be transferred to a central or several local servers from where the SW image may be collected by the IoT units. In such an example, at 4, the DMS may transfer the (e.g., whole) SW package sequence, P, to this server or this set of servers.

[0048] In an example, at 5, the DMS may notify each of the IoT units that may be subject to the upgrade about the availability of the new SW image. The technique may include (e.g., based on such a notification) that the IoT units may contact the DMS for initial SW image parameters or the DMS may (e.g., directly) contact each of the IoT units for the transfer of these parameters. At 5, for each IoT unit (Vu E U) one or more of the following may be performed. For example, a secure (e.g., confidentiality and integrity) protected session based on the key K _u , may be established between each of the IoT unit u and the DMS (e.g, the DMS may establish the session). Using the secure channel, the DMS may transfer one or more of the following parameters to each IoT unit u: IKsw, Ksw, ho, T, and/or a URI, URlsw, which may define where u can find the SW packages associated with the upgrade for download. As described herein (e.g., after receiving the parameters or information transferred from the DMS), the IoT unit u may initialize an internal clock, t = 0 that may be used to track the validity period of the package and may start the clock. In examples, at 6, the DMS may multicast the SW upgrade packages to each of the IoT units u in the network or system.

[0049] The SW image may be collected by the IoT units (e.g., u) according to the examples herein. The actual SW installation may be performed in different ways. The examples herein may be agnostic in the particular SW package retrieval technique that may be used by the IoT unit (e.g., at the IoT side). As described herein this may include (e.g., at least) one or more of the following: multicast of the SW packages by the DMS, download from a central SW image repository, download from a local SW image repository, and/or the like.

[0050] According to an example (e.g., independent of the particular package delivery mechanism used by the DMS, for example), the IoT unit may verify and/or install the image as described herein. FIG. 7 illustrates an example implementation 600, e.g., at an IoT unit, for processing such packages, e.g., as described in examples herein. One or more of the features described in FIG. 7 may be performed. As shown in FIG. 7, at 0, the IoT unit may set a counter (e.g., that may be used to keep track of the number of verified packages in a sequence for the image) for the package to 0 (e.g., j = 0). At 1, the IoT unit may receive and/or retrieve a software package (e.g., the next SW package) Pi.

[0051] The IoT unit may determine whether the package at 2 may still be valid. For example, the IoT unit may compare a time t of the clock that may be initialized and started from the receipt of the package from the DMS with the validity time period T at 2. In an example (e.g., if t > T, e.g., t is above a threshold), the implementation 500 may be aborted by the IoT unit.

[0052] At 3 (e.g., if the package may be valid at 2 or t < T), the IoT unit may access and/or read the index, i, and may determine or make sure it may not have been received already. In an example (e.g., if the package may have already been received), the IoT unit may disregard the package and may receive or get the next package at 1 (e.g., may access the next received package and/or may increment the index to receive the next package thereto) as described herein.

[0053] In an example (e.g., if the package may not have been received), at 4, the IoT unit may verify the integrity of Pi, by calculating MAC'i using the key IKsw, over the fields i, E(Ksw Ji),hi+i}) if 0< i < n-2, and over the fields i, E(Ksw J), if i = n-l .

[0054] At 5, the IoT unit may compare MAC'i with MAG in the received package and if these coincide or match, may accept the package associated with the upgrade. If these do not coincide, the IoT unit may disregard the package and may receive or access a subsequent package as described in one or more examples herein.

[0055] According to an example, at 6a, the IoT unit may store the upgrade package, Pi , in memory and mark it as "non-valid" (e.g., if these coincide, e.g., the MACs match). At 6b, the IoT unit may increment the index for the next package and at 7 may determine whether the number of received packages may be less than the incremented index. In an example, at 7 (e.g., if the number of received packages may be less than ri) 1 may be performed (e.g., get the next SW package associated with the upgrade), otherwise the method 600 may be finished or aborted.

[0056] The SW verification (e.g. image) and upgrade may be performed. For example, the implementation 600 may make an initial or basic verification of the integrity of each package when received at the IoT unit using a common key shared with all IoT units in the system (e.g., the MACs) and a timer. This may provide protection against a DoS attack of the SW upgrades. This may not provide the desired level of security of the actual SW installation. Each of the initially verified packages, may have been marked as "non-valid" and may undergo a final verification before the actual SW installation may be performed. FIG. 8 illustrates an example implementation 700, at IoT unit, for further verifying and installing the upgrade of the image, e.g., as described in examples herein. Implementation 700 may start after the first SW packages may have been received and "preliminary" verified using the MAC based implementation 600. The IoT unit may not need to wait with this verification until the complete image may be downloaded and/or received.

[0057] One or more of the features described in FIG. 8 may be performed. As shown in

FIG. 8, at 1, IoT unit may set the index (e.g., i = 0). At 2, the IoT unit may verify the integrity of package Pi using the hash as described herein. In an example (e.g., if the verification may fail), the IoT unit may request retransmission of Pi.

[0058] At 3, the IoT unit may decrypt the SW upgrade package, h using the key Ksw and mark h as "valid," e.g., in memory. The decryption may be performed and the package may be marked as valid when the integrity may be verified using the hash hi as described herein.

[0059] In an example (e.g., after decryption and marking the package as valid), the index may be incremented at 4. For example, the IoT unit may set i = i+l.

[0060] At 5, the IoT unit may determine whether the index may be less than the number of packages. In an example (e.g., if i < n-l), 2 may be repeated. In an example, 2 may be looped and repeated until i = n-l .

[0061] The IoT unit may verify the integrity of package P _n -i using the hash h _n -i at 6 (e.g., if i = n-l). If such a verification fails, the IoT unit may request retransmission of Pn-i.

[0062] At 7, the IoT unit may decrypt the SW upgrade package, In -i using the key Ksw and mark I _n -i as "valid." In an example, the decryption may be performed and the package may be marked as valid when the integrity may be verified using the hash h _n -i as described herein.

[0063] In an example, at 8 (e.g., upon verification using the hashes), the IoT unit may install the image using the packages (e.g., portions). For example, the IoT unit may install the complete valid upgrade SW image, / = Io,Ii,h, ... ,In-i.

[0064] The examples herein (e.g., the implementations shown in FIG. 3 and 4 and also described in detail in FIGs. 6-8) may enable or allow efficient SW upgrade verification using symmetric cryptographic primitives. The examples may be robust against DoS attacks while still allowing packages to arrive out of order (e.g., as shown in FIG. 4). The DoS protection may be provided using a MAC calculated using a system wide upgrade key and a limited time scope for the upgrade. In such an example, to perform a DoS attack using the upgrade, an attacker may need to break the MAC scheme (e.g., obtain the key for it) and do so within the limited time of validity for the package or piece of the image (e.g., the upgrade SW image). The combination of the above may make it more difficult succeeding with such an attack. The examples may be secure and/or strong in security as the combination of packages or pieces for the image may not be accepted unless each intermediate hash calculation may be valid. As such, the examples herein may provide an efficient and secure SW upgrade mechanism with flexible transport options that may be used with resource constrained IoT units.

[0065] In an example, a one-way hash value may not be included into each SW upgrade package, Pi, but periodically into each t-th SW package, i.e. in Po, Pt-i, Pn-i, ... . and may then be calculated over the SW package following the index of the hash value but each t SW packages following the hash, e.g., ho = \P2t-i), and/or the like. This may provide in principle the same or similar security level, but may save bandwidth in the SW distribution. It may provide that a single SW package may not be verified using this principle but t number of packages may be verified together.

[0066] Such an example may then be that a single hash, ho, may be used for the whole distribution. A possible drawback with such an example may be that a single failure or mistake in one of the SW packages, may need a redistribution of the whole SW image while otherwise, the IoT unit may request retransmission of one or a few of the SW blocks that may include an error. Also, this example may use more storage capacity at the IoT side, as the final verification of the SW image may take place when the complete image is received.

[0067] FIGs. 9A and 9B illustrate an example of a system in which one or more examples described herein may be used and/or implemented. FIGs. 9A and 9B illustrate different industry plants, connected to a common plant DMS over a suitable IP connection. In such an example, each of the control units in plant B may communicate using a WLAN and that some of the control units may be battery driven. The SW upgrade of the units in plant B may be performed. According to the examples herein, this may be applied via one or more of the following.

[0068] A plant DMS may distribute a SW image upgrade to the units in plant B. The plant DMS may divide the new SW image into n distinct pieces (e.g., portions), may select symmetric integrity and confidentiality protection keys, IKsw, and Ksw., and/or may generate n protected SW upgrade packages, P = Po, P1 P2, ... ,Pn-i, e.g., as described herein. The plant DMS may transfer or send the protected SW distribution P to a local server in plant B.

[0069] The DMS may notify each of the control units in plant B of the availability of a

SW image upgrade and may request them to contact the DMS. Over an individual, integrity and/or confidentiality protected channel between the DMS and the different control units in plant B, the following information may be transferred IKsw, Ksw, ho, T, URIsw

[0070] The different control units in plant B may contact the local sever and request the n

SW packages from the server. Each of the packages may be verified as described herein (e.g., according to the methods 300, 400, 600 and 700), for example, e.g., prior to allowing the new SW image to be installed.

[0071] In an example, a local attacker at plant B may be trying to disturb the SW upgrade with the purpose of delay the SW upgrade or make some of the control units in plant B nonfunctional. The attacker may consider one or more of the following. The attacker may try to modify the SW packages at the local server at plant B, may try set up its own local server, replacing the valid one, and put false SW image on its own local server, and/or may try to intercept requests for new SW packages from control units and modify the responses to these requests.

[0072] The attempt to modify the packages at the local server may succeed but unless the attacker has access to the key IKsw, such modification may be detected by the control units (e.g., directly) when the package is received by the control unit. In such a case, the package may then be disregarded. As such, it may not cause damage on the control unit (e.g., but it may cause the SW upgrade as such to fail and that must be repeated). In an example (e.g., even if the attacker may set up an own false local upgrade server), the attacker may not be able distribute false SW upgrade packages that may be accepted by the control units from this sever without access to IKsw. As such, an attempt by the attacker to modify SW upgrade responses according to providing false packages and/or modifying responses may be detected by the control units.

[0073] In an example (e.g., if the attacker managed to get hold of, IKsw), the attacker may be able to produce false upgrade package. This may, for instance, be done by compromising a single control unit in plant B, and using this unit to get hold of IKsw when the DMS may request the update. This may give the attacker access to the initial hash, ho. If this compromise may not have been done prior to the start of the distribution of the new SW image, the attacker may have the time T available to do this compromise, otherwise it may be too late for him/her trying to perform the attack. With this attack, the attacker may fool the control units to store a false SW upgrade image on the units, and, may succeed with a DoS attack. This may not cause a false SW upgrade to take place, as the attacker may not be able to change the initial hash value, ho, distributed individually by the DMS to each control unit during the secure set-up phase according to the examples herein. This value on the other hand, may be used for the verification of the complete SW upgrade chain and if the upgrade SW image actually may be accepted in the end by the control unit. In such an example, to succeed with fooling a unit to a false update, the attacker may compromise each control unit individually.

[0074] FIG. 10A depicts a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0075] As shown in FIG. 10A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, and/or 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, and/or 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0076] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and/or 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a and/or 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0077] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell. [0078] The base stations 114a and/or 114b may communicate with one or more of the

WTRUs 102a, 102b, 102c, and/or 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0079] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0080] In another embodiment, the base station 114a and the WTRUs 102a, 102b, and/or

102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0081] In other embodiments, the base station 114a and the WTRUs 102a, 102b, and/or

102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0082] The base station 114b in FIG. 10A may be a wireless router, Home Node B,

Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c,

102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 10A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0083] The RAN 103/104/105 may be in communication with the core network

106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and/or 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.

Although not shown in FIG. 10A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0084] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a,

102b, 102c, and/or 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0085] Some or all of the WTRUs 102a, 102b, 102c, and/or 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, and/or 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 10A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0086] FIG. 10B depicts a system diagram of an example WTRU 102. As shown in FIG.

10B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element

122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory

130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 10B and described herein.

[0087] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 10B depicts the processor 118 and the transceiver 120 as separate components, it may be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0088] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface

115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0089] In addition, although the transmit/receive element 122 is depicted in FIG. 10B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117. [0090] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0091] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random- access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0092] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0093] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0094] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0095] FIG. IOC depicts a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. IOC, the RAN 103 may include Node-Bs 140a, 140b, and/or 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The Node-Bs 140a, 140b, and/or 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and/or 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0096] As shown in FIG. IOC, the Node-Bs 140a and/or 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the

RNC142b. The Node-Bs 140a, 140b, and/or 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, and/or 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0097] The core network 106 shown in FIG. IOC may include a media gateway (MGW)

144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0098] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. [0099] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0100] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0101] FIG. 10D depicts a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0102] The RAN 104 may include eNode-Bs 160a, 160b, and/or 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and/or 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, and/or 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0103] Each of the eNode-Bs 160a, 160b, and/or 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 10D, the eNode-Bs 160a, 160b, and/or 160c may communicate with one another over an X2 interface.

[0104] The core network 107 shown in FIG. 10D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0105] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and/or

160c in the RAN 104 via an SI interface and may serve as a control node. For example, the

MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and/or 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and/or 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0106] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and/or 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and/or 102c, managing and storing contexts of the WTRUs 102a, 102b, and/or 102c, and the like.

[0107] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0108] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0109] FIG. 10E depicts a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, and/or 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0110] As shown in FIG. 10E, the RAN 105 may include base stations 180a, 180b, and/or 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and/or 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for

communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, and/or 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, and/or 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0111] The air interface 117 between the WTRUs 102a, 102b, and/or 102c and the RAN

105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and/or 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, and/or 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0112] The communication link between each of the base stations 180a, 180b, and/or

180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, and/or 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, and/or 102c.

[0113] As shown in FIG. 10E, the RAN 105 may be connected to the core network 109.

The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0114] The MIP-HA may be responsible for IP address management, and may enable the

WTRUs 102a, 102b, and/or 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the

WTRUs 102a, 102b, and/or 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0115] Although not shown in FIG. 10E, it should, may, and/or will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and/or 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0116] Although the terms device, M2M, unit, IoT, UE, and/or WTRU may be used herein, it may and should be understood that the use of such terms may be used interchangeably and, as such, may not be distinguishable.

[0117] Further, although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware

incorporated in a computer-readable medium for execution by a computer or processor.

Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.