Patent Application
20140177506
The present invention relates generally to wireless communication systems, and, in particular, to Multimedia Broadcast/Multicast Service communication systems.
Starting in Release 9 of the Third Generation Partnership Project (3GPP) standards, evolved Multimedia Broadcast/Multicast Service (eMBMS) will be supported. With eMBMS, cells are grouped together into simulcast areas to simultaneously transmit identical information. These simulcast areas are called Multicast Broadcast Single Frequency Network (MBSFN) Areas. An MBSFN Area is identified on the 3GPP LTE (Long Term Evolution) air interface by an 8-bit field called an MBSFN-AreaID, and as a result there are only 256 possible MBSFN-AreaIDs (that is, the values from 0 to 255). All eNodeB cells in a MBSFN Area transmit the MBSFN-AreaID in a System Information Block 13 (SIB-13). Further, the 8-bit MBSFN-AreaID is a Public Land Mobile Network (PLMN) wide identifier (ID), and therefore there are only 256 such area ID values available for the entire PLMN network.
On Jan. 9, 2011, the Federal Communications Commission issued an order mandating the use of a single PLMN-ID for the nationwide 700 MHz public safety broadband network. However, by using a single, nationwide PLMN-ID, the 256 MBSFN ID space is insufficient to uniquely identify MSFBNs within the PLMN.
eMBMS is considered an important technology for providing mission critical Push-to-Talk (PTT) service for public safety, particularly important for densely populated talkgroups. An architecture of mission critical group services takes advantage of the underlying 3GPP eMBMS service. In a mission critical group services architecture, when a user equipment (UE) learns of a change in its MBSFN-AreaID, the UE reports the new MBSFN-AreaID(s) to a group services server to inform the server which MBSFNs to include in PTT calls (much like in Land Mobile Radio (LMR) systems where the ZC tracks radios to sites). However, the MBSFN ID space in the nationwide network is limited to 256 values, which results in a severe shortage of MBSFN-Area IDs for identifying broadcast areas as planned in mission critical group services (for example, there are not enough MBSFN IDs to cover even 10% of the 3,134 counties in the U.S.). Thus, as applied to a mission critical group service, when a UE reports its MBSFN-AreaID to the group services server, the MBSFN-AreaID reported will become an ambiguous value since multiple MBSFN areas throughout the US will use the exact same MBSFN-AreaID. One may note that 3GPP did not intend the MBSFN-AreaID to be unique within a PLMN, just unique with respect to neighboring MBSFNs.
Therefore, there is a need for an updated mechanism for a client, or UE, to report its MBSFN Area such that an eMBMS-enabled application desiring eMBMS area information can uniquely identify the MBSFN Area serving the UE.
One of ordinary skill in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments of the present invention. Also, common and well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention.
To address the need for a method and an apparatus that provide an updated mechanism for a client, or UE, to report its MBSFN Area such that an eMBMS-enabled application desiring eMBMS location information can uniquely identify the MBSFN Area serving the UE, a method and evolved Multimedia Broadcast/Multicast Service (eMBMS)-enabled infrastructure device are provided that identify an eMBMS area associated with a user equipment UE by receiving, from the UE, a Multicast Broadcast Single Frequency Network (MBSFN) Area update message from a user equipment, wherein the MBSFN Area update message includes an eMBMS area identifier that uniquely identifies an MBSFN Area and includes an extension identifier derived from one or more of a cell identifier, an eNodeB identifier, an identifier of a group of cells, a service identifier, a tracking area identifier, and a paging area identifier, and optionally further may include an MBSFN AreaID, and determining an MBSFN Area serving the user equipment based on the received eMBMS area identifier.
Generally, an embodiment of the present invention encompasses a method for providing evolved Multimedia Broadcast/Multicast Service (eMBMS) area information in a Multimedia Broadcast/Multicast Service (MBMS) communication system. The method includes receiving a Multicast Broadcast Single Frequency Network (MBSFN) Area update message from a user equipment, wherein the MBSFN Area update message includes an eMBMS area identifier that uniquely identifies an MBSFN Area and comprises an extension identifier derived from one or more of a cell identifier, an eNodeB identifier, an identifier of a group of cells, a service identifier, a tracking area identifier, and a paging area identifier, and determining an MBSFN Area serving the user equipment based on the received eMBMS area identifier.
Another embodiment of the present invention encompasses a method for providing eMBMS area information in an MBMS communication system. The method includes detecting, by a user equipment (UE), a cell change from an old cell to a new cell, and determining, by the UE, whether the old cell supports MBMS and whether the new cell supports MBMS. The method further comprises, in response to determining that the new cell supports MBMS, determining whether the new cell is associated with a different MBSFN-AreaID than an MBSFN-AreaID associated with the old cell and, when the new cell is associated with a different MBSFN-AreaID than an MBSFN-AreaID associated with the old cell, sending a MBSFN Area update message that includes an eMBMS area identifier comprising a MBSFN-AreaID and an extension identifier derived from one or more of a cell identifier, an eNodeB identifier, an identifier of a group of cells, a service identifier, a tracking area identifier, and a paging area identifier.
Yet another embodiment of the present invention encompasses an eMBMS-enabled infrastructure device comprising a processor that is configured to receive an MBSFN Area update message from a user equipment, wherein the MBSFN Area update message includes an eMBMS area identifier that uniquely identifies an MBSFN Area and comprises an extension identifier derived from one or more of a cell identifier, an eNodeB identifier, an identifier of a group of cells, a service identifier, a tracking area identifier, and a paging area identifier, and determine an MBSFN Area serving the user equipment based on the received eMBMS area identifier.
Still another embodiment of the present invention encompasses an eMBMS-enabled user equipment comprising a processor that is configured to detect a cell change from an old cell to a new cell and determine whether the old cell supports MBMS and whether the new cell supports MBMS. The processor further is configured to, in response to determining that the new cell supports MBMS, determine whether the new cell is associated with a different MBSFN-AreaID than an MBSFN-AreaID associated with the old cell and, when the new cell is associated with a different MBSFN-AreaID than an MBSFN-AreaID associated with the old cell, send an MBSFN Area update that includes an eMBMS area identifier comprising a MBSFN-AreaID and an extension identifier derived from one or more of a cell identifier, an eNodeB identifier, an identifier of a group of cells, a service identifier, a tracking area identifier, and a paging area identifier.
The present invention may be more fully described with reference to
eMBMS-enabled application level infrastructure device 102 facilitates transport of media (for example, voice, data, video, etc.) from one or more source applications to one or more destination devices (such as members affiliated with a communication group, such as a talkgroup) over the LTE system. As such, the infrastructure device may be, for example, a computer-aided dispatch (CAD) server, a media server, a Push-to-Talk (PTT) call controller, a Broadcast Multicast Service Center (BM-SC), a Group Application Server, and so on and, for ease of reference, is referred to herein as Group Application Server 102. In one illustrative embodiment, Group Application Server 102 is an application server in a packet data network providing application layer services to a UE, such as UE 142, connected to E-UTRAN 134 that are authorized and have the capabilities to use these services. In this instance, Group Application Server 102 provides PTT services to the UE. Other services may include, for example, distribution of video, distribution of images, distribution of data, etc.
In one illustrative embodiment, Group Application Server 102 communicates with a UE, such as UE 142, using control signaling described in OMA-TS-PoC_ControlPlane-V1—0—3-20090922-A and OMA TS PoC UserPlane-V1—0—3-20090922-A (and any subsequent revisions, hereinafter referred to the OMA PoC TS), which defines the procedures of a Push-to-Talk Over Cellular (PoC) Client (e.g., the UE) and a PoC Server (e.g., the Group Application Server 102). The OMA PoC TS references Session Initiation Protocol (SIP) (for example as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 3261 dated June 2002, and any subsequent revisions) as an enabling control protocol for requests for initiating and ending media transmissions and other control signaling. Therefore, some aspects of the present teachings are described by reference to protocols and message structures described in the OMA PoC TS. However, the present teachings are not limited to the use of OMA PoC but can be extended to other protocols both standard and proprietary. Group Application Server 102 further includes an eMBMS Area Database 104 that maintains an identifier of an eMBMS area, for example, a Multicast-Broadcast Single Frequency Network (MBSFN) area, of each UE, such as UE 142, served by the Group Application Server, that is, a location of the UE with respect to a provision of eMBMS services to the UE.
EPC 108 is an all-IP core network that provides mobile core functionality that, in previous mobile generations (2G, 3G), has been realized through two separate sub-domains: circuit-switched (CS) for voice and packet-switched (PS) for data. EPC 108 enables the above-mentioned all IP end-to-end delivery of media: from mobile handsets and other user equipment with embedded IP capabilities, over IP-based eNodeBs, across the EPC and throughout the application domain, IMS (IP Multimedia Subsystem) and non-IMS.
UE 142 also may be referred to in the art as a subscriber unit, a subscriber station, an access device, an access terminal, a mobile station, a mobile device, a user terminal, and the like. UE 142 can be any type of communication device, such as a data terminal used in a vehicle, a radio, a cell phone, a mobile data terminal, a Personal Digital Assistants (PDAs), a laptop computer, a two-way radio, and any other device capable of operating in a wired or wireless environment and that can be used by a user in the system.
The elements of E-UTRAN 134 and of EPC 108, Group Application Server 102, and UE 142 implement protocols and signaling in compliance with Third Generation Partnership Project (3GPP) Technical Specifications (TSs), including, but not limited to, 3GPP TSs 26.346 and 23.246, which describe aspects of 3GPP MBMS. Further, the terms LTE communication system, LTE system, and Evolved Packet System (EPS) are used interchangeably herein and are each defined as being inclusive of the E-UTRAN 134 and the EPC 108 but not inclusive of the Group Application Server 102 or UE 142. Moreover, while only a limited number of EPC and E-UTRAN elements, one UE, and one Group Application Server are shown in
Referring now to
Each eNodeB 140 maintains, in its at least one memory device 304, one or more identifiers of the eNodeB and or a cell served by the eNode B, for example, an eNodeB identifier (eNodeB ID), a cell identifier (Cell ID), an E-UTRAN Cell ID (ECI), or an E-UTRAN Cell Global Identifier (ECGI). As is known in the art, the eNodeB regularly broadcasts such one or more identifiers in overhead messages, so that a UE residing in a coverage area served by the eNodeB can determine its serving eNodeB and/or associate measurements with an eNodeB sourcing the signal. Further, each eNodeB 140 maintains, in the at least one memory device 304 of the eNodeB, a mapping of the cell and/or eNodeB identifiers to MBMS-SAIs, which mapping is pre-programmed into the eNodeB.
Group Application Server 102 maintains, in at least one memory device 504, eMBMS Area Database 104. eMBMS Area Database 104 maintains a mapping of, for example and as is described in greater detail below with reference to
Further, access to RAN-specific eMBMS configuration/provisioning (for example, the cell/eNodeB-to-MBMS SAI mappings configured in eNodeBs 140) is assumed to be available to Group Application Server 102 and/or can be pre-provisioned into the Group Application Server. In such a case, eMBMS Area Database 104 may be configured with one or more tables mapping eNodeB/cell identifiers to one or more of identifiers of a group of cells within a PLMN, such as service area identifiers (SAIs), a service identifier associated with an MBMS service to which the UE has subscribed, such as a Temporary Mobile Group Identity (TMGI), and a tracking, or paging, area identifier associated with the cell where the UE is located, and further mapping the eNodeB/cell identifiers to MBSFN-AreaIDs. For example,
UE 142 further maintains, in at least one memory device 204, an identifier of the cell or eNodeB currently serving the UE, and an identifier of an eMBMS service area, for example, an MBSFN-AreaID, currently serving the UE. The UE may obtain such identifiers from system messages monitored by the UE, which identifiers then are stored by the UE in at least one memory device 204.
Each of UE 142, eNodeBs 140, EPC elements 110-116, and Group Application Server 102 further includes a respective one or more network interfaces (one shown) 206, 306, 406, and 506 that are operatively coupled to the corresponding processor and that are used for passing signaling, also referred to herein as messaging, for example, messages, packets, datagrams, frames, superframes, and the like, between the elements of communication system 100. The implementation of the network interface in any particular element depends on the particular type of network, that is, wired and/or wireless, to which the element is connected. Where the communication system supports wireless communications, the network interfaces 206, 306, 406, 506 include elements including processing, modulating, and transceiver elements that are operable in accordance with any one or more standard or proprietary wireless over-the-air interfaces, wherein some of the functionality of the processing, modulating, and transceiver elements may be performed by means of the processing device through programmed logic such as software applications or firmware stored on the memory device of the system element or through hardware.
The embodiments of the present invention preferably are implemented within UE 142, eNodeBs 140, EPC elements 110-116, and Group Application Server 102, and more particularly with or in software programs and instructions stored in the respective at least one memory device 204, 304, 404, 504 and executed by respective processors 202, 302, 402, 502 associated with the of the UE, eNodeBs, EPC elements, and Group Application Server. However, one of ordinary skill in the art realizes that the embodiments of the present invention alternatively may be implemented in hardware, for example, integrated circuits (ICs), application specific integrated circuits (ASICs), and the like, such as ASICs implemented in one or more of UE 142, eNodeBs 140, EPC elements 110-116, and Group Application Server 102. Based on the present disclosure, one skilled in the art will be readily capable of producing and implementing such software and/or hardware without undo experimentation.
Referring again to
As described in the 3GPP TSs, a radio access network (RAN) such as E-UTRAN 134 can be partitioned into one or more eMBMS service areas, with each eMBMS service area covering a particular geographical area in which eMBMS transmissions to the UE can occur. An MBMS service area comprises one or more MBSFN Areas each identified by a MBSFN-AreaID. Further, each MBSFN Area generally includes multiple cells, wherein a cell is defined as being inclusive of a single eNodeB's coverage area or a portion of an eNodeB's coverage area and can be identified by a cell identifier. As such, the present teachings also apply to a logical partitioning of E-UTRAN 134 where there is a one-to-many correspondence between the eMBMS service area and MBSFN Area.
SGW 114 routes and forwards user point-to-point data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies. There are also links between SGW 114 and the eNodeBs for transporting media that are not shown in
E-UTRAN 134 comprises multiple cells each served by an eNodeB. As shown in
Further, E-UTRAN 134 comprises multiple (in this example three) MBSFN Areas 126, 128, and 130, each having a same number (for example, six as depicted in
Referring now to
Based on the detected cell information, UE 142 determines (706) whether a cell change has occurred, that is, whether the UE is in the coverage area of a new cell (as opposed to an old cell). When the UE detects that it is in the coverage area of a new cell, and based on the detected MBSFN-AreaID or a failure to detect an MBSFN-AreaID, UE 142 determines (708) whether the UE is within coverage of MBMS, and in particular within coverage of an MBSFN, and further determines (714) whether the UE has changed MBSFN Areas, that is, whether the UE has detected a new, as opposed to a previously detected (by the UE), MBSFN-AreaID.
In response to determining (708) that the UE is not within coverage of MBMS, that is, in response to a failure to detect an MBSFN-AreaID in association with the new cell, the UE further determines (710), by reference to its at least one memory device 204, whether the cell currently serving the UE supports MBMS, that is, whether the UE maintains an MBSFN-AreaID in association with the old cell. If neither the new cell nor the old cell supports MBMS, then logic flow diagram 700 ends (718). If the new cell does not support MBMS but the old cell does support MBMS, then the UE performs (712) an eMBMS service area update with Group Application Server 102, indicating, to the server, that the UE has moved to a new cell that does not support MBMS (for example, a “NULL” area), for example, by reporting that MBSFN AreaID=NULL or by reporting a “NULL MBSFN” using a known value or bit sequence to inform that the UE is no longer reachable via MBMS.
In response to determining (708) that the UE is within coverage of MBMS in the new cell, but that the UE has not changed (714) eMBMS service areas, there is no need for the UE to report the MBSFN-AreaID and logic flow diagram 700 ends (718). However, in response to determining (708) that the UE is within coverage of MBMS in the new cell and that the UE has changed (714), in the new cell, to a new eMBMS service area, UE 142 performs (716) an eMBMS service area update to identify its new eMBMS service area to Group Application Server 102, and logic flow diagram 700 then ends (718). More particularly, the UE transmits an eMBMS area identifier, and more particularly an MBSFN-AreaID plus additional eMBMS area information as described in greater detail below, to Group Application Server 102 in a MBSFN Area update message, for example, an MBSFN-AreaID Update message, which can take any suitable form depending on the protocols used in the communication system. For example, UE 142 may include the MBSFN Area update message in a SIP message, such as a SIP PUBLISH message. The eMBMS area identifier uniquely identifies, throughout a Public Land Mobile Network (PLMN), a specific MBSFN Area serving the UE. Preferably, a UE, such as UE 142, would not send the MBSFN Area update message upon every cell handover, but rather would send the message only upon detecting a change in MBSFN-AreaID coverage.
Referring now to
That is, eMBMS area identifier 800 includes an ‘extension identifier (ID)’ comprising an extension to first data field 802 or one or more second data fields 804, which extension/one or more second data fields comprises values derived from one or more of: one or more identifiers of a cell 806 where the UE is located, for example, one or more of an eNodeB identifier, a cell ID (CELL ID), an E-UTRAN Cell ID (ECI), or an E-UTRAN Cell Global Identifier (ECGI), a Mobile Country Code (MCC), and a Mobile Network Code (MNC) (preferably, if using an MCC, then also using an MNC); an identifier of a group of cells 808 within a PLMN, such as a MBMS service area identifier (SAI) (a 16 bit identifier that uniquely identifies a group of cells within a PLMN), a service identifier 810 associated with an MBMS bearer service to which the UE has subscribed, such as a Temporary Mobile Group Identity (TMGI); and a tracking, or paging, area identifier 812 associated with the cell where the UE is located, such as a Tracking Area Identifier (TAI), an MCC, and an MNC (again, preferably, at least an MNC if also using an MCC). Thus, by including one or more of a cell identifier, a MBMS service area identifier, a MBMS service identifier, and a tracking, or paging, area identifier, along with an MBSFN-AreaID, in an eMBMS area identifier, the MBSFN serving a UE shall be associated with a unique eMBMS area identifier, regardless of whether the MBSFN shares an MBSFN-AreaID with another MBSFN Area. The extension ID comprises values derived from the above one or more identifiers in the sense that the extension ID may include, for example, one or more of the identifiers themselves, concatenated versions of one or more of the identifiers, or values output by an algorithm whose input comprises one or more of the identifiers.
In another embodiment of the present invention, the eMBMS area identifier may only include the extension identifier. For example, suppose an MBMS SAI maps uniquely to one MBSFN Area (a 1:1 mapping). In such an instance, when an MBMS SAI is included in an MBSFN Area update message (for example, in the extension identifier field), then there is no need to also include an MBSFN-AreaID as the MBSFN-AreaID would merely be redundant of the MBMS SAI.
Referring now to
However, if, at step 906, Group Application Server 102 determines that the UE can receive messaging through MBMS, then the Group Application Server determines (912), based on the reported eMBMS area identifier, a set of one or more MBSFN Areas serving the UE, wherein each MBSFN Area in the set of MBSFN Areas is associated with an MBSFN-AreaID, and wherein each MBSFN Area's associated MBSFN-AreaID matches the MBSFN-AreaID included in the eMBMS area identifier.
In one embodiment of the present invention, the eMBMS area identifier included in the MBSFN Area update message may comprise a cell and/or eNodeB identifier (ID) and an MBSFN-AreaID. In such an instance, Group Application Server 102 can map the received cell/eNodeB ID to an MBMS SAI and then to one or more possible MBSFN Areas. The MBSFN-AreaID is then used to verify the specific MBSFN Area. This combination of cell/eNodeB ID and MBSFN-AreaID uniquely identifies the MBMS coverage area in which the UE is located. Thus from the combination of reported cell/eNodeB ID and MBSFN-AreaID, the UE's MBSFN Area can be reported unambiguously.
In another embodiment of the present invention, the eMBMS area identifier included in the MBSFN Area update message may comprise an MBMS SAI and MBSFN-AreaID. In this case, Group Application Server 102 may merely review a subset of table 600, that is, the MBMS SAI-to-MBSFN Area mapping. This combination uniquely identifies the eMBMS service area in which the UE is located. Thus, from the combination of reported MBMS SAI and MBSFN-AreaID, the UE's MBSFN Area can be reported unambiguously. However, typically, in standard 3GPP, the MBMS SAI is not provided to the UE. Therefore, in this embodiment, MBMS SAI information may be broadcast to UEs, for example, via an application-defined MBMS announcement channel or by other MBMS announcement procedures or configuration messaging. In still other embodiments of the present invention, other out-of-band mechansims could be used to configure a UE with a mapping of MBMS SAIs-to-MBSFNs, or the entirety of table 600.
In yet another embodiment of the present invention, the eMBMS Area identifier included in the MBSFN Area update message may comprise a Tracking Area Code (TAC) from a SIB-1 of a system information message rather than a cell identifier such as a Cell ID, an ECI, or an ECGI. The TAC is contained within SIB-1 and uniquely identifies a paging geography within a PLMN. This may be advantageous for cases where tracking areas and MBSFNs are aligned or for cases in which the combination of TAI and MBSFN guarantees uniqueness within a PLMN-ID. In such an instance, eMBMS Area Database 104 would be configured with a mapping between tracking area identifiers and MBSFN-AreaIDs.
In still another embodiment of the present invention, wherein RAN-specific MBMS configuration/provisioning may not be made available to Group Application Server 102, the Group Application Server may use a TMGI reported in combination with MBSFN Area update message. The TMGI is a PLMN unique identifier and could be used by the Group Application Server to identify the MBMS coverage area. The TMGI could be used as an extension identifier in the eMBMS area identifier to identify a specific MBSFN Area.
In response to determining the set of one or more MBSFNs serving the UE, Group Application Server 102 compares (914) the eMBMS area identifier to extended MBSFN identifiers maintained by eMBMS Area Database 104, for example, in table 600, to determine if there is a match. For example, in one such embodiment of the present invention, Group Application Server 102 may determine a set of MBSFN Areas based on the evolved Multimedia Broadcast/Multicast Service (eMBMS) area identifier, wherein each MBSFN Area in the set of MBSFN Areas is associated with an MBSFN-AreaID and select an MBSFN Area of the set of MSBFN Areas that corresponds to the extension identifier included in the eMBMS area identifier. In another such embodiment of the present invention, Group Application Server 102 may identify a set of MBSFN Areas based on the extension identifier included in the eMBMS area identifier and select an MBSFN Area of the set of MSBFN Areas based on the MBSFN-AreaID included in the eMBMS area identifier.
For example, and referring to table 600, Group Application Server 102 may compare the extension information included in the eMBMS area identifier to table 600 to see if the eMBMS area identifier matches a Cell ID, and/or SAI, and MBSFN-AreaID combination depicted in table 600. If the eMBMS area identifier included in the MBSFN Area update message does not match (914) any of the eMBMS area identifiers maintained by eMBMS Area Database 104, Group Application Server 102 determines (908) that the UE is outside of the MBMS coverage of the Group Application Server and may notify (910) one or more applications that the UE is outside of MBMS coverage and is not eligible for MBMS services. Logic flow 900 then ends (920).
If the eMBMS area identifier included in the MBSFN Area update message matches (914) an eMBMS area identifiers maintained by eMBMS Area Database 104, Group Application Server 102 updates (916) the UE's eMBMS service area by storing the received information in eMBMS Area Database 104, and if necessary deleting any stale or outdated eMBMS area information for UE 142. Group Application Server 102 then can use this information to identify the specific MBSFN Areas to include for media distribution to the UE. Group Application Server further may notify (918) one or more applications of the identity of the specific MBSFN Areas serving the UE. Logic flow 900 then ends (920).
In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.
The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially,” “essentially,” “approximately,” “about,” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
