FORWARDING

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62/207,483 filed 20-Aug-2015 (Attorney Docket Reference 12691US01), which is incorporated herein by reference.

BACKGROUND

[0002] The present disclosure is generally directed to the fields of communications and software defined networking (SDN), including, for example, to routing and/or forwarding operations in a software defined networking (SDN) based transport network.

[0003] Software-defined networking (SDN) is an emerging paradigm that separates the control plane from the data plane in conventional Layer 2 (L2) switching equipment. With this approach, a SDN-based system may deploy one or more centralized SDN controllers that perform control functions, including, for example, setting of appropriate flow table entries and/or configuring SDN switches appropriately for switching functions. SDN specifications such as OpenFlow (See https//www.opennetworking.org) define a set of matching rules; one or more of which may be executed responsive to an arrival of a packet at any configured SDN switch. The executed matching rules can lead to selection and/or execution of any of various packet handling operations. These packet handling operations may include, for example, packet forwarding to output/forwarding port operations, packet drop operations and packet forwarding to SDN controller operations. Which of the various packet handling operations that may be selected and/or executed may be based on (e.g., a comparison or evaluation of) the matching rule definition and entries instantiated in a matching field of the packet.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("ref ") in the Figures ("FIGs.") indicate like elements, and wherein:

[0005] FIG. 1 is a block diagram illustrating an example software defined networking (SDN) based network in which one or more disclosed embodiments may be implemented;

[0006] FIG. 2 is a block diagram illustrating an example delivery graph;

[0007] FIG. 3 is a block diagram illustrating an example sub-divided delivery graph;

[0008] FIG. 4 is a block diagram illustrating example packet formats;

- 1 - 647341 5 [0009] FIG. 5 is a block diagram illustrating an example network graph;

[0010] FIG. 6 is a block diagram illustrating an example zoned network graph;

[0011] FIG. 7 is a block diagram illustrating an example packet format;

[0012] FIG. 8A is a diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0013] FIG. 8B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 8A;

[0014] FIG. 8C is 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. 8A;

[0015] FIG. 8D is 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. 8A; and

[0016] FIG. 8E is 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. 8A.

DETAILED DESCRIPTION

[0017] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and/or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed or otherwise provided explicitly, implicitly and/or inherently (collectively "provided") herein.

[0018] Introduction

[0019] As noted above, software-defined networking (SDN) is an emerging paradigm that separates the control plane from the data plane in conventional Layer 2 (L2) switching equipment. With this approach, a SDN-based system may deploy one or more centralized SDN controllers that perform control functions, including, for example, setting of appropriate flow table entries and/or configuring SDN switches appropriately for switching functions. SDN specifications such as OpenFlow define a set of matching rules; one or more of which may be executed responsive to an arrival of a packet at any configured SDN switch. The executed matching rules can lead to selection and/or execution of any of various packet handling operations. These packet handling operations may include, for example, packet forwarding to output/forwarding port operations, packet drop operations and packet forwarding to SDN controller operations. Which of the various packet handling operations that may be selected and/or executed may be based on (e.g., a

- 2 - 647341 5 comparison or evaluation of) the matching rule definition and entries instantiated in a matching field of the packet.

[0020] An approach to packet forwarding, developed in parallel with the emergence of SDN, uses fixed length Bloom filter (BF) based identifiers (See P. Jokela, A. Zahemsky, C. Esteve Rothenberg, S. Arianfar, and P. Nikander, "LIPSIN: Line Speed publish/subscribe internetworking," ACM SIGCOMM Computer Communication Review, vol. 39, no. 4, pp. 195-206, 2009 (hereinafter "Jokela")). In this approach, each link in a network is assigned one locally unique identifier ("link identifier" or "LID") for each link direction. For example, if a link is bidirectional, then two LIDs are associated with the link; one for each direction.

[0021] When computing a path from a sender to a receiver, a fixed length BF identifier is computed by performing a logical OR operation on the LIDs of all of the links along the path (i.e., the LIDs are OR-ed together). The fixed length BF identifier is then passed on to the sender. The sender inserts the fixed length BF identifier in packets to be sent along the path, and sends such packets to a next hop along the path.

[0022] At each incoming packet forwarding element, the inserted fixed length BF identifier is extracted. Then, for each outgoing local port of the forwarding element, a logical AND/CMP operation (CMP stands for compare) is performed using the extracted fixed length BF identifier and the LID associated to the corresponding outgoing local port ("outgoing local port LID") of the forwarding element. A result of zero from the AND operation indicates the outgoing local port LID is not among the LIDs used (i.e., OR-ed together) to compute the fixed length BF identifier, and in turn, the link associated with such the outgoing local port is not on the computed path. A non-zero result from the AND operation indicates the outgoing local port LID is (at least presumed to be) among the LIDs used to compute the fixed length BF identifier. Thus, the packet is forwarded on the corresponding outgoing local port responsive to a non-zero result from the AND operation results, but not forwarded responsive to the AND operation resulting in a zero. As an example, assuming the extracted fixed length BF identifier is 0x00000101 and the outgoing local port LID is 0x00000100, the packet is forwarded on the corresponding outgoing local port because the AND operation result is 0x00000100, a non-zero value. This approach supports multipoint delivery and requires only the local port LIDs to be stored at the forwarding element.

[0023] A number of schemes that utilize BF-based forwarding in relation to SDN have been proposed. For instance, one approach interprets a BF identifier as a unique flow identifier for the communication relationship between sender(s) and receivers(s). After configuring each SDN switch along the path, BF-based forwarding from the sender(s) to the receiver(s) is enabled by setting appropriate SDN matching rules for the BF-based forwarding identifier.

- 3 - 647341 5 [0024] Another solution, made public by the EU-funded POINT project through Essex University (hereinafter "Essex University scheme"), relies on the emergence of OpenFlow 1.3 and the existence of ternary content-addressable memory ("TCAM") elements in many SDN switches. This allows for use of "wildcard matching" in SDN switches, and for BF-based forwarding to be implemented through a wildcard matching rule. As an example, the matching rule may specify a flow as 0x00000100/0x00000100 with the output port LID being 0x00000100. The entry of the specified flow to the left of the slash (hereinafter "first entry") represents a value to be tested against and the entry to the right of the slash (hereinafter "second entry") represents a wildcard mask. In wildcard matching, when the first entry is equal to the second entry, wildcard matching is equivalent to an AND/CMP operation.

[0025] As a result, the actual BF identifier can be inserted into any OpenFlow compliant matching field, such as Ethernet in/out addresses or IPv4/6 addresses. In addition, the AND/CMP operation can be implemented by using appropriate matching rules in the SDN switch to perform wildcard matching over entries in the matching field. The only operation to be performed at an SDN controller is that of setting the appropriate matching rules, based on matching fields that have been previously agreed upon (e.g., through standardization). With such solution, BF-based forwarding can be performed without matching rule state in the SDN switches expanding beyond the number of local output ports and independent of the delivery paths being used in the overall system. Also, matching rules only need setting when link information at the SDN switch changes, e.g., at bootstrapping (when the LIDs are first assigned) or when network configuration changes.

[0026] Although appealing in terms of state requirements in SDN switches, the aforementioned SDN BF-based forwarding solution has a significant drawback. This is because existing matching fields are limited in bit length, which in rum, limits the topology size that can be supported. For example, the topology size that can be supported with existing matching fields that occupy Ethernet or IPv4/6 addresses allocations (96 bits overall for Ethernet or 256 bits for IPv6 source/destination addresses), is a few tens of nodes. Such topology size may be significantly reduced if constraints are undertaken to limit or avoid false positive matching, namely, a condition in which packets are forwarded to output ports that are not included in the desired path, leading to unwanted deliveries over the network.

[0027] Yet another solution to BF-based forwarding, described in J. Tapolcai, J. Biro, A. Gulyas, Z. Heszberger and D. Trossen "Optimal False-Positive-Free Bloom Filter Design for Scalable Multicast Forwarding," IEEE/ACM Transactions on Networking, DOI: 10.1109/TNET.2014.2342155, 2014 (hereinafter "Tapolcai"), introduces so-called stages of BF- based forwarding, where each stage is built based on optimization criteria (such as keeping stages

- 4 - 647341 5 small or resulting in no false positive matches). Each stage is then encoded with its (variable length) BF identifier, and an overall BF identifier is created as a concatenation of a stage length identifier and the (variable length) BF identifier of all stages. While allowing for arbitrary topology sizes, the stage-based approach requires more complex operations at stage boundaries, among other issues.

[0028] Any of the aforementioned SDN BF-based forwarding solutions may be suited for a number of use cases. One such use case is that of implementing IP-based services on top of an information-centric networking (ICN) architecture, which in turn is realized over an SDN transport network, as proposed in D. Trossen, M. Reed, J. Riihijarvi, M. Georgiades, G. Xylomenos, N. Fotiou, "IP Over ICN - The Better IP?," EuCNC (European Conference on Networks and Communications), Paris, France, June 29/July 2, 2015 (hereinafter "Trossen").

[0029] ICN constitutes a new paradigm in which content is exchanged by means of information addressing, while connecting appropriate networked entities that are suitable to act as a source of information towards the networked entity that requested the content. Novel architectures have been proposed in this space, such as the PURSUIT project (See http//www.fp7-pursuit.eu, 2014), requiring the partial replacement of current network infrastructure in order to realize the desired network-level functions of these solutions. Migration scenarios foresee that these new architectures could be realized as an overlay over existing, e.g., IP- or local Ethernet-based, architectures. Such migration, however, would still require the transition of user equipment (UE) to an ICN-based solution. With IP-based applications providing a broad range of Internet services in use nowadays, transitioning all of these applications can be a much harder task than the pure transition of the network-level functionality, e.g., protocol stack implementation, in the UE since it also requires the transition of the server-side components, e.g., e-shopping web-servers and alike. Hence, one must assume that IP-based services, and with it purely IP-based UEs, will continue to exist for some time to come. The transition to ICN at the network level, on the other hand, promises a lot, such as increased efficiency through the usage of in-network caches and the spatial/temporal decoupling of sender/receiver in general, the utilization of SDN upgrades for better flow management, etc.

[0030] As discussed above, existing SDN-based BF forwarding solutions may be suited for particular use cases. However, any SDN-based solution for BF-based forwarding should have at least the first three, and preferably, all four of the following desired properties:

[0031] 1. Simple BF-based Matching

[0032] The solution should employ or allow for simple BF-based matching to be used; e.g., an AND/CMP operation over a LID.

- 5 - 647341 5 [0033] 2. Arbitrary Topology Size Support

[0034] The solution should support any size of delivery topology; ideally with no false positive matches occurring during delivery.

[0035] 3. Easy and Scalable SDN Realization

[0036] The solution should allow for an easy and scalable SDN realization. Because future switch forwarding solutions may go beyond today's capabilities of SDN and the underlying protocols, such as OpenFlow, it is desirable that any solution be realizable using existing specifications and without requiring too many extensions of existing protocols.

[0037] 4. Support for spontaneous multicast group formation.

[0038] One advantage of BF identifiers is that a delivery path to one group of receivers can be readily augmented with a delivery path to another group of receivers by OR-ing (performing an OR operation on) the individual BF identifiers to generate a new BF identifier. As such, no centralized function is required for joining groups since these OR operations can be readily performed at the sender side. This ability is of great interest for use cases described in Trossen, among others, for example.

[0039] All of the existing solutions lack one or more of the first three properties, and none of existing solutions have all four properties. For instance, the solution in Jokela does not support topology sizes beyond the fixed length of the BF identifiers defined for it (usually 256 bits). The same is true for the SDN realization described by the Essex University scheme (utilizing TCAM wildcard matching). And the solution in Tapolcai neither supports an easy SDN realization nor spontaneous multicast formation.

[0040] Overview

[0041] Provided herein are procedures, methods, architectures, apparatuses, systems, devices, and computer program products directed to scalable software-defined networking (SDN) Bloom filter (BF) based forwarding. Embodiments thereof comprise simple BF-based matching that is readily realized in SDN and that supports any topology size. Other embodiments thereof comprise simple BF-based matching, readily realized in SDN, that supports any topology size and that retains a simple OR-based multicast group formation capability.

[0042] As would be appreciated by a person of skill in the art based on the teachings herein, encompassed within the embodiments described herein, without limitation, are procedures, methods, architectures, apparatuses, systems, devices, and computer program products to enable communication between two or more devices communicatively coupled to an SDN-enabled transport network, including procedures, methods, architectures, apparatuses, systems, devices, and computer program products for any of: (i) a path computation element to compute suitable

- 6 - 647341 5 path information based on a BF representation of a delivery graph traversed in the network; (ii) a sender to include suitable path information into a transmitted packet, such as path information based on a BF representation of the delivery graph traversed in the network; (iii) intermediary SDN-enabled switches to inspect an incoming packet and perform a suitable BF matching function to determine outgoing packet forwarding port(s); (iv) intermediary SDN-enabled switches to inspect an incoming packet and perform a matching field replacement procedure where no BF match is determined; (v) intermediary SDN-enabled switches to inspect an incoming packet and suitably instruct an SDN controller to perform a matching field replacement procedure when no BF match is determined; and (vi) intermediary SDN-enabled switches to inspect an incoming packet and suitably instruct a locally connected popper element to perform a matching field replacement procedure when no BF match is determined.

[0043] In an embodiment, a method implemented in a software defined networking (SDN) element (e.g., a path computation element) may include obtaining a delivery graph that traverses a plurality of delivery zones, constructing a BF identifier, for each of the plurality of delivery zones, using each of a plurality of forwarding port identifiers (e.g., link identifiers) along the delivery graph within the corresponding delivery zone and constraining the BF identifier to a configured size for a matching field of a packet while satisfying a false positive constraint; providing the constructed BF identifiers to a sender for instantiation into any of the matching field and a payload of the packet. Alternatively, a method implemented in the SDN) element (e.g., a path computation element) may include partitioning a network graph into a set of delivery zones based on using BF identifiers constrained to a configured size for the matching field while satisfying a false positive constraint; computing or receiving a delivery graph; overlaying the delivery graph over the partitioned network graph to determine the plurality of delivery zones from the set of delivery zones; constructing a BF identifier, for each of the plurality of delivery zones, using each of a plurality of forwarding port identifiers along the delivery graph within the corresponding delivery zone; providing the constructed BF identifiers to a sender for instantiation into any of the matching field and the payload of the packet. In an embodiment, the set of delivery zones may include one or more delivery zones not among the plurality of delivery zones. In an embodiment, the method may further include assigning a null BF identifier to any delivery zone of the set of delivery zones not traversed by the delivery graph.

[0044] In an embodiment, a method implemented in the sender may include receiving, from the SDN element, the plurality of BF identifiers; instantiating the plurality of BF identifiers into any of the matching field and the payload; and injecting the packet into the SDN network for BF-based forwarding towards one or more receivers. In an embodiment, the plurality of BF identifiers may

- 7 - 647341 5 include a first BF identifier and one or more second BF identifiers, and instantiating the plurality of BF identifiers into any of the matching field and pay load may include instantiating the first BF identifier in the matching field and the second BF identifiers in the payload. In embodiment, the method may further include any of (i) instantiating the payload with a count information element (IE) that indicates a count of the plurality of BF identifiers included in the packet; (ii) instantiating an index IE into the payload to indicate a next one of the plurality of BF identifiers to be used; and (iii) instantiating a length IE into the payload to allow for inferring which matching field information to use and a length of each of the plurality of BF identifiers.

[0045] In an embodiment, a method implemented in an SDN switch may include receiving, from the sender, a packet comprising the plurality of BF identifiers; extracting a first of the plurality of BF identifiers from the matching field; preforming a forwarding operation based on first of the plurality of BF identifiers and one or more matching rules of a simple BF-based matching function provisioned into the SDN switch; and on condition that the forwarding operation yields a matching output/forwarding port of SDN switch, passing the packet to the matching output/forwarding port of SDN switch. Alternatively, on condition that the forwarding operation fails to yield a matching output/forwarding port of SDN switch, sending the packet to a SDN element; receiving, from the SDN element, a modified packet having a second of the plurality of BF identifiers instantiated in the matching field; extracting the second of the plurality of BF identifiers from the matching field; preforming a forwarding operation based on the second of the plurality of BF identifiers and the one or more matching rules; and on condition that the forwarding operation yields a matching output/forwarding port of SDN switch, passing the modified packet to the matching output/forwarding port of SDN switch.

[0046] In an embodiment, a method implemented in a SDN element (e.g., in a popper node and/or a SDN controller) may include receiving, from the SDN switch, a packet comprising the plurality of BF identifiers; wherein a first of the plurality of BF identifiers is instantiated in the matching and a second of the plurality of BF identifiers is instantiated in another portion of the packet; extracting the second of the plurality of BF identifiers; instantiating the second of the plurality of BF identifiers in the matching field of the packet to form a modified packet; and sending the modified packet to the SDN switch for preforming a forwarding operation based on the second of the plurality of BF identifiers and one or more matching rules of a simple BF-based matching function provisioned into the SDN switch. In an embodiment, the plurality of BF identifiers includes a third of the plurality of BF identifiers, and the method further include selecting the second BF identifier over the third BF identifier based on knowledge of any of a zoned delivery graph and network graph comprising the plurality of delivery zones.

- 8 - 647341 5 [0047] In an embodiment, construction of each BF identifier may include performing a logical OR operation to each of the plurality of forwarding port identifiers along the delivery graph within the corresponding delivery zone. In an embodiment, each forwarding port identifier within any delivery zone is unique within such delivery zone. In an embodiment, at least some of the forwarding ports identifiers are globally unique across the plurality of delivery zones. In an embodiment, the plurality of delivery zones may include a first delivery zone adjacent to a second delivery zone, and the plurality of forwarding port identifiers along the delivery graph within the first delivery zone may include a forwarding port identifier associated to a forwarding port of the sender and a receiving port of an SDN switch disposed at boundaries of the first and second delivery zones. In an embodiment, the plurality of forwarding port identifiers along the delivery graph within the second delivery zone may include a forwarding port identifier associated to a forwarding port of the SDN switch.

[0048] In an embodiment, obtaining a delivery graph that traverses a plurality of delivery zones may include any of computing and receiving a delivery graph; and dividing the delivery graph into the plurality of delivery zones, each of which includes an amount of forwarding port identifiers that permits encoding by a BF identifier constrained to a configured size for a matching field of a packet while satisfying a false positive constraint. In any embodiment, the false positive constraint defines no false positive matches.

[0049] Representative SDN-Based System

[0050] FIG. 1 is a block diagram illustrating an example SDN-based system 100 in which one or more disclosed embodiments may be implemented. The example SDN-based system 10 shown in FIG. 1 is for the purpose of illustration and simplicity of exposition. The SDN -based system 100 and/or elements, nodes and functions thereof may be (or implemented in one or more) elements, nodes, functions of a communication system. Details of an example of such communication system are provided below with reference to FIGs. 8A-8E.

[0051] The SDN-based system 100 may include a sender 102a, a receiver 102b and a SDN-based network 105. The SDN -based network 105 may include an SDN controller 107, a path computation element 109, and a plurality of SDN-enabled or SDN switches (collectively "SDN switches") 111 communicatively coupled to a respective plurality of popper elements 113. Each SDN switch 111 may include a dedicated output port for connecting to its corresponding popper element 113.

[0052] Although not shown, the SDN-based system 100 may include more than one sender, more than one receiver, more than one SDN controller, more than one path computation element, etc. The SDN-based system 100 typically includes many more than the four SDN switches 111 shown,

- 9 - 647341 5 but can include less than four. The SDN-based system 100 may include more or less than the four popper elements 113 shown. For example, more than one SDN switch 111 may be coupled to one of the popper elements 113 or all of the SDN switches 111 may be coupled to a single popper element. Alternatively, a popper element (or its associated functionality) may be integrated into, collocated with or otherwise combined with each of the SDN switches 113.

[0053] Each of the sender 102a and the receiver 102b may be or include, without limitation, a user equipment (UE), a server, etc. The sender 102a and the receiver 102b may communicatively connect to the SDN-based network 105 via respective SDN switches 111 and interconnecting links 115. A link identifier (LID) may be assigned to each link direction or forwarding port of each interconnecting link 115 (i.e., if bidirectional, two LIDs are associated with the link, one for each direction). In some instances, the LIDs may be locally unique across the entire SDN-based system 100 or network 105. In other instances, the LIDs may be locally unique within a partition of the SDN-based system 100 or network 105, across a delivery graph and/or across a partition of a delivery graph.

[0054] The SDN controller 107 may perform various control functions. These control functions may include, for example, setting of appropriate flow table entries and/or otherwise configuring the SDN switches 111 appropriately for switching functions. Control plane signaling may be used by the SDN controller 107 and SDN switches 111 to facilitate such control functions.

[0055] The path computation element 109 may perform path computation from the sender 102a to the receiver 102b. The path computation element 109 may construct, generate or otherwise form (collectively "construct") appropriate BF-based identifiers to facilitate BF-based forwarding (e.g., as further detailed herein).

[0056] Initiation of path computation may occur in various ways. It is envisioned that ICN architectures, such as described in Jokela, and/or IP-over-ICN realizations, such as described in Trossen, for example, may utilize this system by initiating appropriate path computation requests based on a successful rendezvous operation in these architectures.

[0057] Basic Bloom Filter (BF) based Forwarding

[0058] FIG. 2 is a block diagram illustrating an example delivery graph 200. For simplicity of exposition, the example delivery graph 200 is described with reference to the SDN-based system 100 of FIG. 1. The delivery graph 200 may include a single sender 102a and a plurality of receivers 102b- 1021, connected via a plurality of switching nodes 111 and a plurality of interconnecting links 115.

[0059] The delivery graph 200 may be computed by the path computation element 109 or other like-type element or function (collectively "path computation element 109"), and may be used by

- 10 - 647341 5 the path computation element 109 to construct a basic fixed length BF identifier that encodes the entire delivery graph.

[0060] The construction of the basic fixed length BF identifier may include encoding each link or associated forwarding port in the delivery graph through an OR operation performed on the LID associated with the link direction (or forwarding port). Because it is fixed length, the resulting fixed length BF identifier can be used to encode a delivery graph up to a certain size (i.e., with a certain total number of links) for a given probability of false positive matches (i.e., detecting a link for forwarding that is not part of the delivery graph on which the fixed length BF identifier was generated). In other words, a tradeoff exists between the maximum delivery graph size that can be encoded and the minimum probability of false positive matches that can be achieved for a given fixed length BF identifier. Hence, relying on such single fixed length BF identifier does not allow for scaling beyond a certain size of a delivery graph. Example estimates for graph size, dependent on a fixed length BF identifier may be found in Jokela.

[0061] Representative Scalable Bloom Filter (BF) based Forwarding

[0062] In one category of embodiments provided herein basic BF-based operation is extended towards topologies of arbitrary size, thereby removing the above described topology size limitation of existing solutions. These embodiments, as described below, rely on zoning a delivery graph, which is computed on a per packet delivery basis.

[0063] In operation, the path computation element 109 may obtain a delivery graph that traverses a plurality of delivery zones of a set of delivery zones. To obtain such delivery graph, the path computation element 109 may compute the delivery graph and then may partition or otherwise divide the delivery graph into a set of delivery zones. Alternatively, the path computation element 109 may partition or otherwise divide the delivery graph into a set of delivery zones in connection with computing the delivery graph. In general, the path computation element 109 may partition (or divide) any delivery graph such that any delivery zone thereof can be encoded with a BF identifier of a specified length ("BF-identifier length") without exceeding a (e.g., pre-defined) probability for false positive matches. Various algorithms may be used to compute the probability for false positive matches as a function of a delivery graph size and BF-identifier length. One example of these algorithms may be found in Jokela. In an embodiment, the path computation element 109 may receive the delivery graph already partitioned into the set of delivery zones.

[0064] The path computation element 109 may construct a BF identifier for each of the plurality of delivery zones, using each forwarding port identifier along the delivery graph within the corresponding delivery zone and constraining the BF based identifier to a configured size for a matching field of a packet header while satisfying a (e.g., pre-defined) false positive constraint.

- 11 - 647341 5 The path computation element 109 may provide the constructed BF identifier to the sender 102a for instantiation into any of (i) a matching field of a packet header and (ii) a packet payload.

[0065] For each packet it intends to send to the receivers 102a-1021, the sender 102a may instantiate the matching field with the BF identifier for the delivery zone that includes the forwarding port identifier of the sender 102a, and the instantiate the remaining BF identifiers into the packet payload. The sender 102a may instantiate the packet with the BF identifiers in other ways, as well.

[0066] The sender 102a may inject the packets into the SDN-based network 105 towards the receivers 102a- 1021. The intermediary SDN switches 111 may inspect each incoming packet and perform a suitable BF matching function to determine outgoing packet forwarding port, if any. The suitable BF matching function may be a simple BF based matching, such as wildcard matching, assuming an appropriate configuration of matching rules in the SDN switches 111 by the SDN controller 107. Each of the SDN switches 111 may have a specific rule to handle a condition when no matching output port is found. This rule may instruct the SDN switch 111 to drop the packet (i.e., assuming that the packet has been wrongfully forwarded to the switch and it should therefore be dropped). Embodiments, however, may use different rules. The SDN switches 111 may perform a matching field replacement procedure where no BF match is determined. Alternatively, the SDN switches 111 may suitably instruct the SDN controller 107 and/or its locally connected popper element 113 to perform a matching field replacement procedure when no BF match is determined.

[0067] Representative examples of the embodiments that comprise simple BF-based matching that is readily realized in SDN and that supports any topology size are provided below in connection with FIGs. 3 and 4.

[0068] Representative Delivery Graph Zoning

[0069] Referring now to FIG. 3, a block diagram illustrating an example delivery graph 300 divided into a plurality of sub-graphs or "delivery zones" is shown. For simplicity of exposition, the delivery graph 300 is described with reference to the SDN -based system 100 of FIG. 1. The delivery graph 300 of FIG. 3 is similar to the delivery graph 200 of FIG. 2, except that the delivery graph 300 may be partitioned or otherwise divided into delivery zones 301, 302 and 303.

[0070] The path computation element 109 may partition (or divide) the delivery graph 300 such that each of the delivery zones 301, 302 and 303 can be encoded with a BF identifier of a specified BF-identifier length without exceeding a (e.g., pre-defined) probability for false positive matches. In an embodiment, the BF-identifier length (for the BF identifier of) for each delivery zone may be defined by, based on and/or constrained to a configured size of a matching field used in the

- 12 - 647341 5 SDN switch operation. In an embodiment, the matching field may occupy Ethernet in/out address information allocations; leading to a total of 96 bits for the BF-identifier length of the BF identifier for each delivery zone. In an embodiment, the matching field may occupy the IPv4 or IPv6 address information allocations, which provides up to 256 bits (IPv6) for the BF-identifier length of the BF identifier for each delivery zone. The delivery graph 300 may be partitioned or divided into more or less than three delivery zones.

[0071] Representative Construction of Delivery Zone BF Identifiers

[0072] Construction of BF identifier, BF1, corresponding to delivery zone 301, may include the path computation element 109 encoding each link or associated forwarding port in the delivery zone 301 through an OR operation performed on the LIDs associated with the link direction (or forwarding port) within the delivery zone 301. The BF identifiers, BF2 and BF3, may be constructed in the same way. In an embodiment, in computing the BF identifier for any one of the delivery zones, the path computation element 109 may treat any receiving SDN switch at a border of such delivery zone akin to a receiver in that output/forwarding ports of the border SDN switches are not included in the BF identifier for the delivery zone. These border SDN switches may also be treated akin to senders to adjacent next-hop delivery zones such that the output/forwarding ports of such border SDN switches are included in the BF identifier for the adjacent next-hop delivery zones.

[0073] Representative Construction of Packets for Delivery

[0074] In an embodiment, after constructing the BF identifiers, BF1, BF2 and BF3, for the delivery zones 301, 302 and 303, the path computation element 109 may deliver such BF identifier information to the sender 102a. In one embodiment, the path computation element 109 may be part (e.g., a function of) of a topology manager (TM) of an ICN architecture, and the delivery of the BF identifier information is performed over an appropriate interface from the TM to the sender 102a.

[0075] The sender 102a may use the BF identifier information to construct one or more packets for delivery to the receivers 102b-1021. The packets may be constructed and/or delivered using any of various packet formats. Example packet formats 401, 403, 405 and 407 that may be constructed and/or used by the sender 102a are shown in FIG. 4.

[0076] Referring now to FIG. 4, each of the packet formats 401, 403, 405 and 407 may include a header structure 409 and a pay load structure 411. The header structure 409 may include a matching field 413. The matching field 413 may be allocated to, for example, a portion (bits) of the header structure 409 otherwise allocated to Ethernet in/out address information in an Ethernet

- 13 - 647341 5 domain. Alternatively, the matching field 413 may be allocated to a portion (bits) of the header format 409 otherwise allocated to be the IPv4 or IPv6 address information in an IP domain.

[0077] The matching field 413 may be instantiated with the BF identifier for the delivery zone that includes the LID of the output/forwarding port of the sender 102a ("first delivery zone"). For example, the matching field 413 may be instantiated with the BF identifier, BF1 (FIG. 3)

[0078] The pay load structure 411 may be instantiated with the remaining BF identifiers, e.g., BF2 and BF3. These payload-based BF identifiers may be inserted at a beginning of the payload structure 411, together with a count information element (IE) 415 that may indicate the number of BF identifiers. The count IE 415 may indicate the total number of BF identifiers or the number of payload-based BF identifiers (total number of BF identifiers minus 1) given the first BF identifier, e.g., BF1, is inserted into the packet header. The count IE 415 may precede the payload-based BF identifiers or be otherwise positioned within the payload structure. Although shown concatenated together, the payload-based BF identifiers may be in positioned apart from one another.

[0079] In some embodiments, as shown in the packet format 403, an index IE 417 may be instantiated into the payload structure 411. The index IE 417 may indicate a next BF identifier to be used for replacement, and may be initialized with a value of zero.

[0080] In some embodiments, as shown in the packet format 405, a length IE 419 may be instantiated into the payload structure 411. The length IE 419 may allow for inferring which matching field information should be used and how long each BF identifier is (in case of mixed matching field deployments).

[0081] In some embodiments, as shown in the packet format 407, both the index IE 417 and the length IE 149 may be instantiated into the payload structure 411.

[0082] Although each of the packet formats 401, 403, 405 and 407 show only a single BF identifier in the header structure 409 with the payload structure 411 carrying the remaining BF identifiers, some or all of the BF identifiers may be instantiated in the header structure 409 instead of the payload structure 411. They may be instantiated into dedicated fields within the header structure 409 (e.g., using a revised L2 packet header format) and/or in fields earmarked or used for other purposes. Additionally, any of the count IE, index IE and length IE may be instantiated in the header structure 409 (e.g., using a revised L2 packet header format) and/or in fields earmarked or used for other purposes. They may be instantiated in addition to, or in lieu of, instantiation in the payload structure 411.

[0083] Representative Popping of BF Identifier at Zone Borders

[0084] After constructing packets, e.g., using any of the packet formats 401, 403, 405 and 407 shown in FIG. 4, the sender 102a may inject the packets into the SDN-based network 105. In an

- 14 - 647341 5 embodiment, within each SDN switch 111, forwarding may be executed on each packet using wildcard matching or other simple BF-based matching, assuming an appropriate configuration of matching rules in each SDN switch 111 by the SDN controller 102.

[0085] In addition to the matching rules, each SDN switch 111 may have a specific rule to handle a condition when no matching output/forwarding port is found. This rule may instruct the SDN switch 111 to drop the packet (i.e., assuming that the packet has been wrongfully forwarded to the switch and it should therefore be dropped). Embodiments, however, may use different rules.

[0086] In one embodiment, when no matching output/forwarding port is found, the SDN switch 111 may forward the packet to the output port associated with the popper element 113. In another embodiment, the SDN switch 111 may forward the packet to the SDN controller 107. In both embodiments, the following procedure may be executed by the popper/SDN controller 113/107. After receiving the incoming packet, the popper/SDN controller 113/107 may inspect its payload and determine the count variable. If the count information is zero, the packet may be dropped (in this case, no other forwarding instruction exists in the packet). If the count information is nonzero, the popper/SDN controller 113/107 may extract the next BF identifier field according to the defined matching field length (e.g., Ethernet in/out or IP 4/6 address information). The popper/SDN controller 113/107 may determine the defined matching field from the length IE 419 field if available in the packet. Alternatively, the defined matching field may be known from standardization of the used matching fields (e.g., the popper/SDN controller 113/107 may be pre- configured with knowledge of the defined matching field).

[0087] In one embodiment (e.g., which may be used with the packet formats 401 and 405 (FIG. 4)), the information may be extracted using the first payload-based BF identifier, removing it from the payload after the popper/SDN controller 113/107 copies the extracted BF identifier into the appropriate matching fields (inferred by the length of the BF identifier), while also decreasing the count variable in the packet.

[0088] In another embodiment (e.g., which may be used with the packet formats 403 and 407 (FIG. 4)), the information may be extracted using the index IE 417, which points to the next BF identifier to be used. The popper/SDN controller 113/107 may copy the extracted BF identifier into the appropriate matching fields (inferred by the length of the BF identifier), while increasing the index variable in the packet (to point to the next BF identifier in the payload). Because the index is increased, the copied BF identifier is not removed from the payload.

[0089] After generating a modified packet for the next delivery zone, the modified packet may be delivered as follows. In embodiments that use the popper element 110 to perform the above operations, the modified packet may be sent back to the SDN switch 111 on the port the popper

- 15 - 647341 5 element 113 is connected to. In embodiments that use the SDN controller 107 to perform the above operations, the modified packet may be sent back to the SDN switch 111 using a SDN controller- switch interface. Due to the replacement of BF1 (or more generally "BFn") with BF2 (BFn+1), the SDN switch 111 can now perform suitable matching operations, which will result in forwarding operations towards delivery zone 302 (delivery zone n+1) and therefore in delivery of the packet to the next SDN switch 111.

[0090] Another category of embodiments of the present disclosure, as further described below, include systems and methods for simple BF-based matching, readily realized in SDN, that supports any topology size and that retains a simple OR-based multicast group formation capability. As such, these embodiments satisfy all four desired properties discussed earlier. These embodiments, as further described below with respect to FIGs. 5, 6 and 7, rely on zoning the network graph, at design time for example (instead of zoning a delivery graph on a per packet delivery basis).

[0091] For the purpose of illustration only, these embodiments are also described with reference to the example SDN -based system 100 of FIG. 1. It is further assumed, in an embodiment, that the path computation element 109 includes information that describes a network graph of the SDN- based network. In addition, the path computation element may include link and/or node state information (e.g., for link load, queue length in buffers), which may be used for calculating delivery graphs between nodes in the network.

[0092] According to embodiments, zoning of the network graph may include partitioning or dividing the network graph into distinct delivery zones so that a desired false positive match criteria can be achieved for each zone given a BF identifier configuration (e.g., BF-identifier length, BF identifier format). In an embodiment, each delivery zone may also include at least one dedicated border node, which is included in at least two zones - unless there is only one zone. These border nodes may perform special operations, in addition to the BF-based forwarding operation, as further described below.

[0093] Representative Zoning of Network Graph

[0094] FIG. 5 is a block diagram illustrating an example network graph 500, including a plurality of nodes, including sender and receiver nodes 102, switching nodes 111, etc., and a plurality of interconnecting links 115. FIG. 6 is a block diagram illustrating an example zoned network graph 600 that results from a zoning of the example network graph 500 of FIG. 5. As shown in FIG. 6, the zoned network graph 600 includes four distinct delivery zones, 601-604.

[0095] In an embodiment, network graph zoning may be performed by the path computation element 109, and may be performed at network setup or whenever network topology changes. After carrying out zoning, the path computation element 109 may inform each switching node 111

- 16 - 647341 5 at a border of a delivery zone ("border node 611 ") of the zone to which it belongs. For this purpose, a border node 611 connecting two zones may be considered a member of a downward zone (i.e., a zone that lies in the direction of outgoing links in the network graph).

[0096] Representative Link Identifier Configuration

[0097] Different LID configurations may be used to generate a BF identifier that can be successfully matched (i.e., which achieves the desired false positive criteria) within each zone. For simplicity of exposition herein, the BF-identifier length of such BF identifier(s) is denoted by m. As mentioned above, in an SDN realization, the length, m, may be equal to 96 bits with the Ethemet in/out fields being used for (wildcard) matching of the BF identifier placed into these matching fields. Alternatively, the length, m, may be 256 bits with the IPv6 source/destination fields being used as matching fields. Further, it is assumed that each link direction of each zone is uniquely (within each zone) labeled with a LID. In an embodiment, the LID configuration may include setting k bits out of the length, m, bits of each LID through an appropriate set of hash functions. In a trivial case, 1 unique bit out of the length, m, bits is used to label a link (i.e., one bit is set to 1 (0) and the remainder m-l bits are set to 0 (1)). In that case, m links can be supported without any false positive occurring, and each zone in a zoned network graph may contain a maximum of m links.

[0098] Bootstrapping of the LID naming may be implemented various ways. Example solutions for such bootstrapping, as outlined for example in the PURSUIT project, may be readily adapted to the network zoning approach described herein. For example, each delivery zone may be treated as a separate network, and the bootstrapping may be executed with a maximum length m for each zone concurrently.

[0099] Representative Construction of BF Identifiers for Zoned Network Graphs

[0100] In an embodiment, for each send/receive (or publish/subscribe) communication, the path computation element 109 may compute or obtains an appropriate delivery graph (not shown) as a sub-graph of the overall network graph, e.g., utilizing constraint-based criteria or using a shortest- path algorithm. An example of the computed delivery graph may be akin to the example delivery graph 200 of FIG. 2.

[0101] The path computation element 109 may overlay the delivery graph with the zoned network graph 600 to determine which of the delivery zones 601-604 that the delivery graph traverses. For the purpose of illustration, it is assumed that the overlay of the delivery graph on the zoned network graph 600 indicates delivery zones 601, 602, and 603 (but not delivery zone 604) are traversed by the delivery graph and that that the sender 102 is located in delivery zone 601.

- 17 - 647341 5 [0102] The path computation element 109 may compute BF identifiers, BF1, BF2 and BF3, for delivery zones 601, 602 and 603 of the zoned network graph 600 spanned by the delivery graph. For delivery zones not spanned by the delivery graph, e.g., delivery zone 604, the path computation element 109 may set its corresponding BF identifier, BF4, to zero.

[0103] Representative Construction of Packets for Delivery for Zoned Network Graph

[0104] In an embodiment, after generating the BF identifier information (BF1-BF4) for the delivery zones 601-604 of the zoned network graph 600, the path computation element 109 may deliver the BF identifier information to the sender 102a. In one embodiment, the path computation element 109 can be part of a TM of an ICN architecture, and the delivery of the BF identifier information may be performed over an appropriate interface from the TM to the sender 102a.

[0105] The sender 102 may use the BF identifier information in constructing packets for delivery. In an embodiment, the sender 102a may, for each of such packets, instantiate the BF identifier of the delivery zone to which it belongs (e.g., delivery zone 601) into matching fields used in the particular SDN environment. The sender 102a may also instantiate all of the zone BF identifiers BF1-BF4 (i.e., including that of its own zone) into the payload of the packet. An example packet format 700 that may be used by the sender is shown in FIG. 7.

[0106] Representative Popping of BF Identifiers at Zone Borders for Zoned Network Graphs

[0107] After constructing packets, e.g., using the packet format 700 shown in FIG. 7, the sender 102a may inject the packets into the SDN-based network 105. In an embodiment, within each SDN switch 111, forwarding may be executed on each packet using wildcard matching or other simple BF-based matching, assuming an appropriate configuration of matching rules in each SDN switch 111 by the SDN controller 107. In another embodiment, packet forwarding may be performed by configuring SDN switches 111 of each zone with an appropriate rule that utilizes the BF identifier of the zone to which the switches belong.

[0108] In addition to configuration with rules as described above, each SDN switch 111 may have a specific rule to handle a condition when no matching output/forwarding port is found. This rule may instructs the SDN 111 switch to drop the packet (i.e., assuming that the packet has been wrongfully forwarded to the switch and it should therefore be dropped). Embodiments, however, may use different rules.

[0109] In one embodiment, when no matching output/forwarding port is found, the SDN switch 111 may forward the packet to the output port associated with the popper element 113. In another embodiment, the SDN switch 111 may forward the packet to the SDN controller 107. In both embodiments, the following procedure may be executed by the popper/SDN controller 113/107.

- 18 - 647341 5 After receiving the incoming packet, the popper/SDN controller 113/107 may inspect the payload and extract the corresponding zone BF identifier field (corresponding to the delivery zone where the SDN switch 111 is located) according to the defined matching field length (e.g., Ethernet in/out or IP4/6 address information allocation). This extraction may rely on knowledge of the delivery zone that the border node 611 belongs to. As described above, in an embodiment, this information is delivered to each border zone by the path computation element 109 in connection with network graph zoning. The extracted zone BF identifier may then be placed into the appropriate matching fields (e.g., Ethernet in/out or IPv4/6 src/dst fields) in the packet header.

[0110] After generating a modified packet for the next zone, the modified packet may be delivered as follows. In embodiments that use the popper element 113 to perform the above operations, the modified packet may be sent back to the SDN switch 111 on the port the popper element 113 is connected to. In embodiments that use the SDN controller 107 to perform the above operations, the modified packet may be sent back to the SDN switch 111 using a SDN controller- switch interface.

[0111] Due to the replacement of BF1 (or more generally "BFn") with BF2 (BFn+1), the SDN switch 111 can now perform suitable matching operations that will result in forwarding operations towards delivery zone 602 (delivery zone n+1) and therefore in delivery of the packet to the next SDN switch 111.

[0112] Embedding into Future OpenFlow Specifications

[0113] One embodiment of the aforementioned popping operations may include the support for such payload operations in future OpenFlow specifications. For instance, such OpenFlow matching rules may include the specification of an index into the payload together with a length information that is used to define the content being copied for the matching operations outlined above. Hence, instead of popping the next zone BF identifier into the matching field (such as Ethernet in/out or IPv4/6), a matching rule may be used in the SDN switch that copies payload information into matching fields. This effectively implements the aforementioned popping operations as a matching rule in the SDN switch, after which the original matching rules can be implemented on the now changed matching field entries. Currently, OpenFlow 1.3/1.4 rules do not support such payload operations (due to performance reasons) but future standardization efforts could see the integration of such payload copy operations.

[0114] Embodiments of the present disclosure satisfy all of the above described desired properties of an SDN BF-based forwarding solution. Specifically, embodiments allow for simple BF-based matching through AND/OR operations, which can be readily implemented on OpenFlow 1.3+ compliant SDN switches through the aforementioned wildcard matching. This is in addition

- 19 - 647341 5 to supporting spontaneous multicast group formation and delivery in any network topology size with no or minimal false positives.

[0115] Example Communications System

[0116] The methods, apparatuses and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. An overview of various types of wireless devices and infrastructure is provided with respect to FIGs. 8A-8E, where various elements of the network may utilize, perform, be arranged in accordance with and/or be adapted and/or configured for the methods, apparatuses and systems provided herein.

[0117] FIG. 8A is 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.

[0118] As shown in FIG. 8A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, 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, 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, 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.

[0119] 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, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), aNode-

- 20 - 647341 5 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.

[0120] The base station 114a may be part of the RAN 104, 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.

[0121] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0122] 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 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 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).

[0123] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A).

[0124] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 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

- 21 - 647341 5 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.

[0125] The base station 114b in FIG. 8A 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. 8A, 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.

[0126] The RAN 104 may be in communication with the core network 106, 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, 102d. For example, the core network 106 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. 8A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0127] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 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

- 22 - 647341 5 connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0128] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 8A 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.

[0129] FIG. 8B is a system diagram of an example WTRU 102. As shown in FIG. 8B, 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 19, 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 sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0130] 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. 8B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0131] 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 116. 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.

- 23 - 647341 5 [0132] In addition, although the transmit/receive element 122 is depicted in FIG. 8B 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 116.

[0133] 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.

[0134] 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 19 and/or the removable memory 132. The non-removable memory 19 may include random-access memory (RAM), readonly 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).

[0135] 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.

[0136] 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 116 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

- 24 - 647341 5 location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0137] 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.

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

[0139] As shown in FIG. 8C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node- Bs 140a, 140b, 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, 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.

[0140] The core network 106 shown in FIG. 8C 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.

[0141] The RNC 142a in the RAN 104 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, 102c with access to circuit-switched

- 25 - 647341 5 networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0142] The RNC 142a in the RAN 104 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, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0143] 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.

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

[0145] The RAN 104 may include eNode-Bs 140a, 140b, 140c, 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 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0146] Each of the eNode-Bs 140a, 140b, 140c 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. 8D, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0147] The core network 106 shown in FIG. 8D may include a mobility management gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. 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.

[0148] The MME 142 may be connected to each of the eNode-Bs 140a, 140b, 140c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the

- 26 - 647341 5 WTRUs 102a, 102b, 102c, and the like. The MME 142 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.

[0149] The serving gateway 144 may be connected to each of the eNode Bs 140a, 140b, 140c in the RAN 104 via the SI interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 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, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

[0151] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 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 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 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.

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

[0153] As shown in FIG. 8E, the RAN 104 may include base stations 140a, 140b, 140c, and an ASN gateway 142, though it will be appreciated that the RAN 104 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 140a, 140b, 140c may each be associated with a particular cell (not shown) in the RAN 104 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the base stations 140a, 140b, 140c may

- 27 - 647341 5 implement MIMO technology. Thus, the base station 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 140a, 140b, 140c 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 142 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 106, and the like.

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

[0155] The communication link between each of the base stations 140a, 140b, 140c 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 140a, 140b, 140c and the ASN gateway 215 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, 100c.

[0156] As shown in FIG. 8E, the RAN 104 may be connected to the core network 106. The communication link between the RAN 104 and the core network 106 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 106 may include a mobile IP home agent (MIP-HA) 144, an authentication, authorization, accounting (AAA) server 146, and a gateway 148. 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.

[0157] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 144 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 146 may be responsible for user authentication and for supporting user services. The gateway 148 may facilitate interworking with other networks. For example, the gateway 148 may provide the WTRUs 102a, 102b, 102c with access to circuit-

- 28 - 647341 5 switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 148 may provide the WTRUs 102a, 102b, 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.

[0158] Although not shown in FIG. 8E, it will be appreciated that the RAN 104 may be connected to other ASNs and the core network 106 may be connected to other core networks. The communication link between the RAN 104 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 104 and the other ASNs. The communication link between the core network 106 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.

[0159] Conclusion

[0160] Although features and elements are provided 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. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0161] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term "video" may mean any of a snapshot, single image and/or multiple images displayed over a time basis. As another example, when referred to herein, the terms "user equipment" and its abbreviation "UE" may mean (i) a wireless transmit and/or receive unit (WTRU), such as described supra; (ii) any of a number of embodiments of a WTRU, such as described supra; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU, such as described supra; (iii) a wireless-capable and/or wired-capable

- 29 - 647341 5 device configured with less than all structures and functionality of a WTRU, such as described supra; or (iv) the like. Details of an example WTRU, which may be representative of any UE recited herein, are provided above with respect to FIGs. 8A-8C.

[0162] In addition, the methods provided 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.

[0163] Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

[0164] Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[0165] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data

- 30 - 647341 5 bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0166] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM")) or non-volatile (e.g., Read-Only Memory (ROM")) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

[0167] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and/or any other computing device.

[0168] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost versus efficiency tradeoffs. There may be various vehicles by which processes and/or systems and/or other technologies described herein may be effected (e.g., hardware, software, and/or firmware), and the preferred vehicle may vary with the context in which the processes and/or systems and/or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and/or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

[0169] The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples may be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and/or other integrated formats. However, those skilled in the art will recognize that some

- 31 - 647341 5 aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[0170] Those skilled in the art will recognize that it is common within the art to describe devices and/or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and/or processes into data processing systems. That is, at least a portion of the devices and/or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and/or control systems including feedback loops and control motors (e.g., feedback for sensing position and/or velocity, control motors for moving and/or adjusting components and/or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.

[0171] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may

- 32 - 647341 5 be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

[0172] With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.

[0173] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having

- 33 - 647341 5 skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0174] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0175] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

- 34 - 647341 5 [0176] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U. S. C. §1 12, ^( 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

- 35 - 647341 5