Management of public keys for verification of public warning messages

This application is identified by Agent Document No. 811083, simultaneously filed, assigned to the assignee of the invention, and incorporated herein by reference, "Management of User Equipment Security System Status for Public Warning System." Related to a US patent application named.

The field generally relates to communication networks and, more specifically, to public warning systems associated with such communication networks.

This section introduces aspects that can help promote a better understanding of the invention. Therefore, the statements in this section should be read with this in mind and should not be understood as approvals for what is or is not in the prior art.

Third Generation Partnership Project (3GPP)^TM) Is 3GPP^TMThe technical specification TS22.268 version 11.3.0 (dated December 2011), which describes the general requirements for public warning systems in telecommunications networks, has been published, the disclosure of which is hereby incorporated by reference in its entirety. It is incorporated in the book.

As disclosed in TS 22.268, timely and accurate alerts, warnings, and important matters regarding disasters and other emergencies, regardless of what communication technology the public uses. There has been interest in ensuring that they have the ability to receive information. As has been known from disasters such as earthquakes, tsunamis, hurricanes, and wildfires, these capabilities are appropriate measures for the public to protect their families and themselves from serious injury or loss of life or property. Is essential to be able to take. This is intended to be done by the public warning system.

<p><nplcit num="1"><text>Technical specifications TS22.268 version 11.3.0</text></nplcit></p>

<p num="0007"> Embodiments of the present invention provide techniques for managing one or more public keys used for verification of one or more messages transferred over a communication network associated with a public alert system.</p><p num="0008"> In one embodiment, the method comprises the following steps: A computing device in a telecommunications network obtains key material for at least one source of messages generated for a public alert system. The computing device also gets the source identifier. The public key is calculated by the computing device from the key material and source identifiers. Therefore, a public key is available to the computing device to verify the message received from the source, which is digitally signed using the source's corresponding private key. In one embodiment, the computing device comprises a user device.</p><p num="0009"> Advantageously, an exemplary embodiment of the present invention allows for less complex key distribution, including the ease of adding a new PWS source public key and the ease of performing key invalidation.</p><p num="0010"> These other features and advantages of the present invention will become more apparent from the accompanying drawings and the detailed description below.</p>

<figref num="1">It is a figure of the communication network by one Embodiment of this invention.</figref><figref num="2A">It is a figure of the method for managing the public key distribution by one Embodiment of this invention.</figref><figref num="2B">It is a figure of an example of the control plane message by one Embodiment of this invention.</figref><figref num="2C">It is a figure of the method for managing the public warning system identifier distribution by one Embodiment of this invention.</figref><figref num="2D">It is a figure of the method for public key and identifier management by one Embodiment of this invention.</figref><figref num="3">FIG. 5 is a diagram of a communication network architecture suitable for implementing public key and identifier management in a public warning system according to an embodiment of the present invention.</figref>

Illustrative embodiments of the present invention are described herein in 3GPP as referenced above.^TMDescribed in the context of a public warning system (PWS) such as PWS as described in TS22.268. Embodiments of the present invention are Long Term Evolution (LTE).^TM) It can be said that it is suitable for implementation in accordance with TS22.268 in communication networks and the like, but alternative embodiments of the present invention are described in other computing environments and communication networks and in TS22.268. It should be understood that it can be implemented by public warning systems other than those that are.

As used herein, with respect to the source of an alert message for a public alert system, an "entity" is a private or public entity that generates and propagates one or more alert messages associated with the public alert system. Refers to the agency or authority of the.

As used herein, "control plane" refers to the functional layer of a communications network protocol stack, the functionality of which is discovery, routing, routing, signaling for computing devices in a communications network. , Or one or more of similar. As such, "control plane messages" are generated and / or transmitted as part of the control plane of the protocol stack associated with the communication network to perform one or more of the previously mentioned control plane functions. This is the message to be sent.

As used herein, a "network operator" (or "telecom operator") owns and operates a telecommunications network (or a portion thereof) and is therefore a subscriber. Refers to a company that provides services to. An example of a network operator is AT &amp; T^TMAnd Verizon^TMIncluding, but not limited to.

As mentioned earlier, there has been an increasing desire and / or need to implement PWS according to communication networks, such as mobile cellular networks. Therefore, the user equipment (UE, or mobile station (MS)) of such a network should have the ability to receive PWS notifications within a given notification area through a mobile cellular network. Is recognized. The UE also alerts one or more people who own the UE, so it knows what to do with these alerts, including how to process and display any alerts received. Should be. Examples of UEs can include, but are not limited to, mobile phones, smartphones, portable computers, tablets, wireless email devices, personal digital assistants (PDAs), or any other mobile computing device.

An example of a PWS as described in TS22.268 is a Commercial Mobile Alert System (CMAS), which sends a warning alert message provided by the alert alert provider to a CMAS-enabled UE. .. CMAS includes three different classes of alert alerts (ie, Presidential, Imminent Threat, Child Abduction emergency). Another example of PWS described in TS22.268 is an earthquake and tsunami warning system provided by a warning notification provider that sends warning notification messages specific to natural disasters such as earthquakes and tsunamis to the UE.

In such a PWS, the UE can receive primary and secondary warning notification messages through the communication network to which the UE is attached. The primary alert message (or primary PWS message) generally preferentially conveys a small amount of alert data (compared to a secondary alert message, eg, a few bytes) and is of interest event (eg, natural). It is understood that it is a message that promptly conveys the imminent occurrence of a disaster). Secondary alert messages (or secondary PWS messages) generally convey a large amount of alert data (compared to primary alert messages) and tell someone what to do and where to go in an emergency. A message that provides text and / or audio to direct to, as well as graphical data including a map to the shelter and a timetable for food distribution.

In addition, TS22.268 negotiates some high-level general requirements for sending alerts: (I) The PWS shall be able to broadcast the warning notification to a plurality of users at the same time without the need for an acknowledgment. (Ii) PWS shall be able to support concurrent broadcasts of multiple warning alerts. (Iii) The warning notification shall be broadcast to the notification area based on geographical information as specified by the warning notification provider. (Iv) It is assumed that the PWS-compatible UE (PWS-UE) in the idle mode can receive the warning notification to be broadcast. (V) PWS shall only be required to broadcast warning notices in a language as specified by regulatory requirements. (Vi) Warning alerts are processed by PWS on a first-in, first-out basis, subject to regulatory requirements. (Vii) Receiving warning alerts and presenting them to the user shall not preempt an active voice or data session. (Viii) Warning notices shall be limited to emergencies in which life or property is in imminent danger and some response action should be taken. This requirement does not prohibit the use of implemented operator networks (ie, broadcast technology) as alert alerts are used for commercial services.

TS22.268 negotiates some high-level general requirements for alert content: (I) PWS shall not modify or convert the alert content specified by the alert provider. (Ii) Warning notification has the following five elements: (1) event description, (2) affected area, (3) recommended behavior, (4) expiration date (has a time zone), (5) ) Source agency, which is expected to include, (Iii) Additional content elements can be presented in accordance with regulatory requirements, (Iv) Uniform resource locators in alerts when network traffic is already increasing dramatically as individuals contact police, firefighters, and emergency personnel, as well as their loved ones. There is concern that a locator (URL) or phone number can exacerbate wireless network congestion. Therefore, the warning alert by TS22.268 will immediately and weaken the traffic load on the Public Land, such as a URL or dialable number. It should not include anything that is forced into the Mobile Network (PLMN).

In addition, TS22.268 negotiates a high level of general requirements for security associated with alert content: (I) PWS only broadcasts alerts due to authenticated and authorized sources, (Ii) The integrity of warning notification shall be protected, (Iii) PWS shall protect against false warning notification messages.

That is, it is recognized that one important requirement for PWS is the desire / need to verify the authenticity of the primary and secondary PWS messages received through the communication network. Such verification is possible by protecting the integrity of the PWS message with the private key (PrK) of the source of the PWS message. The source is, for example, one or more computing devices associated with an entity such as a government or private agency tasked with a given geographic or urban location for generating and propagating PWS messages. Can be.

To verify the authenticity of the PWS message, the UE must have the public key (PuK) of the PWS message source. These public keys are not secret, but their distribution is an important task. The reason is that there may be more than one licensed PWS source (eg, Hurricane Center, Seismic Activity Bureau, Nuclear Safety Commission, etc.) anywhere. In addition, the assumption is that PWS messages will be available to roaming UEs (as is known, roaming UEs are within their home network. A UE that is not running, but is running within the visited network).

As further described herein, embodiments of the present invention utilize an identifier of an entity (PWS source in the case of PWS) to generate a public key (PuK) for that entity. The use of identifier-based public key management allows for less complex key delivery, including the ease of adding new PWS source public keys and the ease of performing key revocation. Less complex key management provides better and faster security procedures that need to occur prior to PWS message authentication. The less complex key revocation procedure provides better assurance that the PWS message is due to an authenticated and authorized PWS source.

FIG. 1 shows a communication network 100 according to an embodiment of the present invention. As shown, the UE 102 accesses the communication network 100 via one access network of the access networks 110, 120, and 130. For brevity, only one UE is shown. However, it is understood that two or more UEs can access the communication network 100. It should also be understood that the UE 102 can be configured to communicate with all three access networks shown in FIG.

The access network 110 is, as is known in the art, a GSM® Edge Radio Access Network (Radio Access Network) (GERAN, where GSM refers to a global system for mobile communications). Includes a base transceiver base station (BTS) 112 and a base station controller (BSC) 114. The access network 120, as is known in the art, is a UMTS terrestrial radio access network (UTRAN, where UMTS refers to a Universal Mobile Telecommunications System). And a base station (NodeB) 122 and a radio network controller (radio network). Includes controller (RNC) 124. The access network 130, as is known in the art, is an evolved UTRAN network (E-UTRAN) and includes a base station (eNB) 132. Access networks 110, 120, and 130 can have multiple elements of network elements shown and other network elements not shown, but for brevity, only one of the network elements mentioned above is used. It is understood that it is shown within each access network.

The communication network 100 as shown in FIG. 1 also includes a core network 140, which, as is known in the art, is a mobility management entity (MME) 142 and a cell broadcast center. (Cell network center) 144 is included. Other network elements can be part of the core network.

In addition, the cell broadcast entity (CBE) 150 is part of the communication network 100. CBC144 and CBE150 are part of the PWS infrastructure. "Cell broadcast" is the ability to broadcast one or more messages to a mobile station (UE) within a "cell" (as used in mobile cellular networks). Point to. In the case of PWS, the message is the warning notification message described above.

The CBE150 can represent, for example, the entity that is the source of the alert message. CBC144 is a network element from which messages are delivered. However, in the case of the E-UTRAN access network 130, the MME 142 receives these messages from the CBC 144, delivers the messages to the E-UTRAN access network 130, and the E-UTRAN access network 130 then delivers the messages to the UE. Forward.

The protocol between CBC144 and the network elements of the access network is 3GPP.^TMAs defined in TS48.049, TS25.419, and TS23.401, the disclosure is incorporated herein by reference.

An embodiment of the present invention relates to managing the public key required to authenticate a warning alert message (eg, primary and secondary messages as described above) received by a UE from a PWS source. Provides an identifier-based approach.

Identifier-based encryption (IBE) protocols have been proposed as an alternative to traditional public key protocols that require the presence of a public key infrastructure. The basic idea behind IBE is that the public key is derived from the identifier associated with this key, and that derivation is a well-known mathematical function. Therefore, there is no need to combine an entity's identifier with a public key through the use of certificates. The reason is that the public key is derived from the identifier using an inherently known algorithm. Note that with respect to IBE, the message is encrypted with the recipient's IBE public key. The latter is just an entity that can decrypt these messages using the associated private key (to its identifier) known only to the recipient. This private key executes a key generation function (Key Generation Function) (KGF) (private key generator Private Key). Produced by a trusted third party called the Generator (PKG). Therefore, for IBE, any requirement for identifier validation using certificates managed by a large public key infrastructure will be obsolete. The only cryptographic material required by the sender of a message for the IBE to encrypt the message is publicly known as required to generate the recipient's public key. A set of cryptographic parameters.

The identifier-based cryptographic protocol is presented by Boneh and Franklin (Dan Boneh, Matthew K. Franklin, "Identity-Based Encryption from The Weil Pairing", see (Dan Boneh, Weil Pairing) Advanced200. Incorporated herein by reference. This asymmetric cryptographic cryptographic protocol allows stakeholders to use "identity" (eg, email-ID or domain name) as a public key, and RSA (Rivest, Shamir, and Adleman). Eliminates the need for large-scale public key infrastructure, which is often associated with public key cryptography such as. Boneh and Franklin's approach to the problem is finite. It uses a bilinear map of elliptic curves on field) and relies on the bilinear decision Diffie-Hellman problem.

The protocol involves the following mathematical tools and parameters: Let E be an elliptic curve on the finite field F, and let P be a point of a large prime order.

Let e be a bilinear map on E of E × E G. A typical example is the pairing of Weil, where G is the group of roots of the nth root of 1, where n is a function of the number of points with respect to E on F.

Let s be a non-zero positive integer and a secret stored in the key generation function (KGF). This is a system-wide secret and is not exposed to the outside world of KGF.

P_pub= SP is assumed to be the public key of the system known to all parties. Recall that since E is a group, sP indicates a point within E.

H_１Let be a known hash function. The hash function takes a string and assigns the string to a point on the elliptic curve, i.e. H on E_１(A) = Q_AIs. Here, A is usually an identifier and, likewise, A's public key.

d_A= SQ_AIs a private key calculated by KGF and sent only to A.

H_２Let be a known hash function. The hash function takes an element of G and assigns that element to the string.

Let m be a message that must be encrypted and sent to A. The cryptographic functions described by Bonne and Franklin are:

g_A= E (Q_A, P_pub), And let r be a random number.

Encryption_A(M) = (rP, mxor H_２(G_A^r)), In other words, the encrypted output of m has two coordinates u and v. Here, u = rP and v = mxor H_２(G_A^r). Note that "xor" is an exclusive OR logical function.

To decrypt (u, v), A restores m using the following formula: m = v xor H_２(E (d)_A, U))

The official proof is a simple exercise in a bilinear map, and fact A is the secret d._AHas (a private key known to A, but not known to other parties). Similarly, first d_AIt should also be noted that the KGF that calculated the can decrypt the message as well, resulting in the KGF being the de facto key escrow server.

In addition to the examples described above, it should be understood that other forms of IBE are known.

As a result, using IBE principles, authorities can verify signatures between individual parties without prior distribution of keys. This is very useful when pre-delivery of authenticated keys is inconvenient or infeasible due to technical constraints. However, in order to sign the message, the authorized user must obtain the appropriate private key from PKG. The caveat with this approach is that the PKG must be very reliable as it can generate a private key for any user and therefore can sign the message without authorization.

An embodiment of the present invention utilizes the principle of IBE by verifying a PWS warning notification message. More specifically, an embodiment uses the identifier of a given PWS source to generate a public key (PuK) for that source, which is then used to use the corresponding private key of the source. Then, based on the message being digitally signed, the message is verified as being due to its source. It should be understood that public key cryptographic operations for validating digitally signed messages using public and private key pairs are well known in the art and are not further described herein. Is.

Further, it is understood that key management consists of key distribution and key revoke. In the case of public key cryptography, it is usually the revocation task that can pose a challenge. However, the ease of the key revocation procedure is one of the strengths of IBE compared to normal key management.

In the simplest case where no other parameters are required, the PWS source identifier (eg, Marine_and_hurricane_at Yucatan_Peninsula) can be used to generate the PuK of the PWS source. This identifier can also be tied to a PuK expiration date, thus eliminating the need for complex schemes for PuK revocation. This identifier can also be tied to a service area identifier (ID) or message expiration date, thus providing a higher particle size for the PWS public key.

Advantageously, in this case, observe that the source of the PWS message uses its private key to sign the message. As soon as the recipient of the PWS message receives it, it validates the signature using the PuK (ie, the identifier) of the source of the PWS message.

It should also be appreciated that the messages transferred between the PWS source and the UE are not required but can be encrypted. An example of an encryption protocol that can be used is an identifier identifier-based encryption protocol.

FIG. 2A is a diagram of a method 200 for managing public key distribution according to an embodiment of the present invention. Method 200 illustrates the delivery of a public key associated with a key generation function (PU-KGF) in relation to a control plane message (in this case, a NAS SMC message) in the context of an E-UTRAN access network 130 (FIG. 1). Shown in. The methods for access networks 110 and 120 and other access networks can be the same or similar.

KGF is, for example, a private key generator (Private Key). It should be understood that it can be implemented in a given network as a secure database managed by a Generator (PKG). KGF (PKG) can be part of MME142 (FIG. 1) or some other network element. By receiving the PU-KGF, this allows the UE 102 to authenticate the local and / or centralized KGF to obtain a list of local PWS sources with the appropriate key material for each source. Key material can be obtained from KGF directly or through some other network element, such as MME. The point is that the key material is protected using the KGF public key-private key pair. This key material for each PWS source, along with a unique identifier for each source (received in the manner as described in the context of FIG. 2C below), is used by the UE 102 for all PWS sources everywhere. Enough to derive the public key. That is, the KGF provides the UE with a key material, which is the public key for each PWS source from the list of PWS identifiers (eg, PWS_ID1, PWS_ID2, etc.) along with the PWS source identifier (described further below). For example, it is possible to derive one public key for one PWS source.

As shown in FIG. 2A, in an initial attach or TAU (tracking area update) procedure as shown in step 202, the UE 102 sends an initial attach request to the MME 142 through the eNB 132. As shown, in step 204, an EPS authentication and key agreement (AKA) procedure can be performed between the UE 102 and the MME 142. EPS represents an evolved packet system, which is the name given to the E-UTRAN wireless network.

At step 206, the MME 142 associates the PU-KGF with the NAS SMC message (eg, inserts, attaches, appends, merges, joins, or does the same) and has the KGF public key. The message is transmitted to the eNB 132, and the eNB 132 then transfers the message having the KGF public key to the UE 102 in step 208. Upon receiving the NAS SMC message in step 208, the UE 102 stores the PU-KGF transmitted from the MME 142 by the NAS SMC message. It should be understood that NAS SMC messages are typically used by the MME to initialize the NAS signaling security context between the UE and the MME. NAS SMC messages can also be used to modify the NAS security algorithm for the current EPS security context in use.

Advantageously, an embodiment of the present invention utilizes NAS SMC messages (more generally, control plane messages), whereby a UE operating within a given broadcast area (eg, control plane message). , Roaming and home-based UEs) to transmit and utilize PU-KGF. The UE can then verify that the key material for each PWS that the UE receives from the KGF is due to the authentic source.

At steps 210 and 212, the UE 102 returns the NAS SMC complete message to the MME 142 through the eNB 132. The NAS SMC termination message usually includes the UE's IMEISB (International Mobile Equipment Identity Software Version). Next, in step 214, the UE 102 is notified of the approval of the attach or TAU request by the MME 142.

FIG. 2B is an example of a control plane message according to an embodiment of the present invention. More specifically, FIG. 2B shows the message format 220 for NAS SMC messages generated and transmitted by the MME 142 (in step 206 of FIG. 2A) and transferred to the UE 102 (in step 208 of FIG. 2A). As shown, content elements 222-240 (ie, protocol discriminator 222, security header type 224, security mode command message identifier 226, selected NAS security algorithm 228, NAS key set identifier 230, spare half octet 232, Regenerated UE security capability 234, IMEISV request 236, regenerated nonce_UE238, and nonce_MME240) is 3GPP^TMIt is described in TS24.301, the disclosure of which is incorporated herein by reference. Further content (more generally related) added to the message is PU-KGF242. It should be appreciated that the PU-KGF242 may be part of the spare half octet 232, or be added to the SMC payload, for example, in alternative embodiments.

In an alternative embodiment, it should be appreciated that PU-KGF can be acquired by the UE via the PLMN Operator Universal Integrated Circuit Card (UICC) distribution channel.

FIG. 2C is a diagram of a method 250 for managing public warning system identifier distribution according to an embodiment of the present invention. As shown in FIG. 2C, the PWS source identifier is loaded into the UE by an unprotected Cell Broadcast Service (CBS) message. CBS is 3GPP^TMIt is described in TS 23.041, the disclosure of which is incorporated herein by reference. Once such a list of PWS sources and the corresponding PWS source key material obtained from the KGF are stored in the UE, this is sufficient to authenticate the PWS message signed by the private key of the PWS source. ..

As shown, in step 252, the MME 142 forwards the Write-Replace request message to the eNodeB 132. This message contains the PWS source identifier within a given area. The MME can use the tracking area ID (identifier) list to determine the eNodeB within the transmission area. If the tracking area ID list is empty, the message is forwarded to all eNodeBs connected to the MME.

At step 254, the cell broadcast service sends a CBS message to the UE 102 via the eNodeB 132. This message contains the PWS source identifier within a given area. Since this message sending method is not guaranteed, multiple attempts can be made.

At step 256, the eNodeB 132 sends a Write-Replace request message to the MME 142. This informs the MME of an attempt to send a message to the UE 102.

From the Write-Replace response message returned by eNodeB 132, the MME 142 determines in step 258 whether the transmission was successful or unsuccessful and generates a trace record.

Alternatively, it should be understood that the PWS source identifier can be pre-located within the UE (in the mobile device or ME or in the UICC).

Following the stages described above in the context of FIGS. 2A and 2C, the UE 102 validates the signature of any PWS alert message with the public key derived from the signing entity identifier and the signature algorithm communicated in the PWS message itself. it can.

FIG. 2D is a diagram of Method 260 for managing public keys and identifiers according to an embodiment of the present invention. More specifically, method 260 shows the steps performed by the UE 102 in order to be able to verify the PWS warning alert message.

At step 262, the UE acquires the key material for at least one PWS source. This is achieved after the UE has securely acquired the public key of the KGF (Fig. 2A), and the UE uses the public key to source the key material that the UE subsequently receives, i.e. the KGF. Verify that it is from.

At step 264, the UE obtains the PWS source identifier non-securely (FIG. 2C). Recall that this can be done through CBS messages.

At step 266, the UE calculates the public key from the key material and identifier of the PWS source (using the well-known IBE calculation, as described above).

At step 268, the UE uses the public key to verify the alert message received from the PWS source that is digitally signed using the corresponding private key of the PWS source.

It should be understood that the order in which the UE performs steps 262 and 264 is not necessarily important to the method, i.e. the UE may receive the key material before the identifier. This may be the case if the deployment scenario does not require unique key material for the PWS source identifier. However, for example only, if the key material received from the KGF has a unique expiration date for a given PWS source identifier embedded in the key material, the UE will PWS before requesting the key material from the KGF. You should have a list of source identifiers.

Finally, FIG. 3 shows the architecture of a communication network 300 suitable for implementing PWS public key and identifier management according to an embodiment of the present invention.

As shown, the computing devices 302-1, 302-2, 302-3, ..., 302-P are operably coupled via the communication network medium 304. The network medium can include any network medium through which the computing device can communicate, including, for example, wireless and / or wired media. As an example, the network medium can carry IP (Internet Protocol) packets from end to end and can include any communication network of the communication networks described above. However, the present invention is not limited to any particular type of network medium.

The computing device shown in FIG. 3 is the various networks shown in the context of FIGS. 1, 2A, and 2C, namely UE102 and BTS112, BSC114, NodeB122, RNC124, eNB132, MME142, CBC144, and CBE150. It should be understood that it represents an element. The two or more components of FIG. 1 may also share the computing device shown in FIG.

As will be readily apparent to those skilled in the art, the computing device of FIG. 3 can be implemented as a programmable computer operating under the control of computer program code. The computer program code is stored in a computer (or processor) readable storage medium (eg, memory), and the code will be executed by the computer's processor. Given this disclosure of the present invention, one of ordinary skill in the art can readily create suitable computer program code to implement the methods and protocols described herein.

However, FIG. 3 generally shows an exemplary architecture for each computing device communicating over a network medium. As shown, the computing device 302-1 includes a processor 310, memory 312, and a network interface 314. As such, each computing device in FIG. 3 can have the same or similar computing architecture.

As used herein, the term "processor" is a signal processor, microprocessor, microcontroller, application specific integrated circuit (ASIC), field programmable gate array (FPGA), or other type of processing. It should be understood that it is intended to include circuits and one or more processing devices that include parts or combinations of such circuit elements. Similarly, as used herein, the term "memory" is an electronic memory associated with a processor, such as random access memory (RAM), read-only memory (ROM), or other types of memory. Is intended to be included in any combination. Further, as used herein, the phrase "network interface" is intended to include any circuit or device used to interface a computing device to a network and other network components. Will be done. Such circuits can include conventional transceivers of the type well known in the art.

Accordingly, software instructions or codes for implementing the methods and protocols described herein are prepared to be stored and utilized in one or more of the associated memory devices, such as ROM, fixed or removable memory. Once created, it can be loaded into RAM and executed by the processor. That is, each computing device shown in FIG. 3 can be individually programmed to perform the respective steps of the methods and protocols shown in FIGS. 1, 2A, and 2C.

Illustrative embodiments of the invention have been described herein with reference to the accompanying drawings, but the invention is not limited to these exact embodiments and deviates from the scope or gist of the invention. It should be understood that various other changes and modifications can be made by one of ordinary skill in the art without doing so.