METHODS, APPARATUSES AND SYSTEMS FOR SESSION ESTABLISHMENT IN A WIRELESS COMMUNICATION NETWORK

Methods, apparatus and systems for session establishment in a wireless communication network are disclosed. In one embodiment, a method for session establishment, includes: receiving a first session establishment request associated with a first user equipment device (UE) communicatively coupled to a first communication network; in response to the first session establishment request, allocating a first bridge port number to the first UE, wherein the first bridge port number identifies a first port of a first network bridge that communicatively couples the first UE with the first communication network; and transmitting the first bridge port number to be received by the first UE.

TECHNICAL FIELD

The disclosure relates generally to wireless communications and, more particularly, to methods, apparatuses and systems for session establishment in a wireless communication network.

BACKGROUND

The 4th Generation mobile communication technology (4G) Long-Term Evolution (LTE) or LTE-Advance (LTE-A) and the 5th Generation mobile communication technology (5G) face more and more demands. One of the important goals of the 5G system is to support industrial Internet and vertical industry applications, where a time sensitive network (TSN) can meet the strict requirements of industrial applications for both delay and reliability. A 5G system may support the TSN traffic if the 5G system is enhanced to serve as a virtual bridge for the TSN network. That is, from the perspective of the TSN network, the 5G system will look like a TSN bridge entity.

For a particular TSN network, a virtual TSN bridge can utilize the same user plane function (UPF) of the 5G system to handle all PDU sessions targeted to that particular TSN network. However, it is currently unclear how the 5G system will manage such a virtual TSN bridge. Thus, existing systems and methods for establishing and managing PDU sessions in a TSN are not entirely satisfactory.

SUMMARY OF THE INVENTION

In one embodiment, a method for session establishment, includes: receiving a first session establishment request associated with a first user equipment device (UE) communicatively coupled to a first communication network; in response to the first session establishment request, allocating a first bridge port number to the first UE, wherein the first bridge port number identifies a first port of a first network bridge that communicatively couples the first UE with the first communication network; and transmitting the first bridge port number to be received by the first UE.

In another embodiment, a method for session establishment, includes: receiving a first session establishment request by an access and mobility control function (AMF) node of a 5G system, the first session establishment request being associated with a first user equipment device (UE) node communicatively coupled to a first TSN; in response to the first session establishment request, allocating a first bridge port number to the first UE by either a user plane function (UPF) node or a session management function (SMF) node of the 5G system; and transmitting bridge information by the UPF node or SMF node to be received by the first UE node, wherein the bridge information comprises at least the first bridge port number.

In further embodiments, a system for session establishment, includes: a first network node configured to receive a first session establishment request associated with a first user equipment device (UE) communicatively coupled to a first communication network; and a second network node configured to, in response to the first session establishment request, allocate a first bridge port number to the first UE, wherein the first bridge port number identifies a first port of a first network bridge that communicatively couples the first UE with the first communication network, and wherein the second network node is further configured to transmit the first bridge port number to be received by the first UE.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Various exemplary embodiments of the present disclosure are described below with reference to the accompanying figures to enable a person of ordinary skill in the art to make and use the present disclosure. As would be apparent to those of ordinary skill in the art, after reading the present disclosure, various changes or modifications to the examples described herein can be made without departing from the scope of the present disclosure. Thus, the present disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order and/or hierarchy of steps in the methods disclosed herein are merely exemplary approaches. Based upon design preferences, the specific order or hierarchy of steps of the disclosed methods or processes can be re-arranged while remaining within the scope of the present disclosure. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in a sample order, and the present disclosure is not limited to the specific order or hierarchy presented unless expressly stated otherwise.

FIG. 1illustrates an exemplary block diagram of a centralized mode TSN network100, which is an exemplary environment in which the methods, apparatuses and systems disclosed herein may be implemented. As shown inFIG. 1, the TSN network100includes a centralized network controller (CNC)102, a first TSN bridge104, a second TSN bridge106, a third TSN bridge108, a first TSN end station110and a second TSN end station112. In some embodiments, the CNC102controls and configures all the TSN nodes104-112within the TSN network100. In some embodiments, each of the nodes104-112can report its respective capabilities and neighborhood topology (e.g., other nodes it is directly connected to) to the CNC102. After getting such information, the CNC102can construct the topology of the entire TSN network100. Thus, when TSN service traffic is to be established, the CNC102can calculate an end-to-end path for the TSN service traffic taking into account respective TSN node capabilities, link capabilities and the TSN network topology.

In some embodiments, some or all of the first, second and third TSN bridges104,106and108can be implemented as a switch or router with enhanced functionality, as described in further detail below. In some embodiments, some or all of the first, second and third TSN bridges104,106and108can be implemented by utilizing enhanced nodes of a 5G system, as described in further detail below. Furthermore, in accordance with various embodiments, each of the first and second TSN end stations110and112may be any device, machine or system that is capable of communicating with (i.e., “communicatively coupled to”) one or more of the TSN bridges104,106and108.

For example, in some embodiments, the first TSN end station110may be surgical machinery in a hospital having communication circuitry for performing wireless and/or wired communications via the Internet. Such surgical machinery can receive commands from a remotely located surgeon to perform a surgery in real-time and, therefore, requires low-latency and high-reliability communications with the remotely located surgeon (not shown), who provides commands to the surgical machinery. The second TSN end station112may be surgical interface that can be operated by the surgeon to provide commands to and control the surgical machinery located far away (e.g., across the globe) from the surgeon. Needless to say, such a procedure requires an extremely low-latency and highly reliable communication session to be established and maintained. This is just an example of the many possible applications of a TSN network and the embodiments of the invention described herein.

Referring still toFIG. 1, each TSN node (e.g., bridge nodes104,106and108, and end stations110and112) can report its capabilities to the CNC102. For example, the first TSN bridge104can transmit the following capability information per port pair within the node: (Bridge-1 ID, port1, port2) {(class 0, 2 ns delay), (class 1, 5 ns delay), . . . (class 8, . . .)}, which indicates supported traffic class and corresponding delay associated with the indicated port pair. In this example, for the port 1/port 2 pair, for class 0 traffic there is a 2 ns delay from when the TSN bridge104receives the data in port1 and sends out the data in port 2, or vice versa. For class 1 traffic, this delay will be 5 ns from when the TSN bridge104receives the data in port 1 and sends out the data in port 2, or vice versa, etc. As would be understood by persons of skill in the art, actual delay information is more complex and includes many factors and parameters. Currently, there are eight defined traffic classes for TSN communications.

As mentioned above, each TSN node104-112can report its topology information to the CNC102. In some embodiments, a TSN node or entity can use the802.1AB protocol specification to find its “neighbor” information (e.g., other nodes it is directly connected with). For example, the first TSN bridge104can report the following information to the CNC102: (Bridge-1 ID, port-1, TSN end station-1 ID, port-1, link delay=5 μs), (Bridge-1 ID, port2, Bridge-2 ID, port1, link delay=1 μs). This means that port 1 of Bridge-1 connects to port-1 of TSN end station-1, with a link delay of 5 μs, and the port-2 of Bridge-1 connects to port-1 of TSN Bridge-2, with a link delay of 1 μs.

After receiving the topology information from each of the nodes in the TSN Network100, the CNC102can then calculate the topology and capabilities of the entire TSN network100. When TSN service traffic is to be established, the CNC102can calculate an end-to-end path according to the TSN node capabilities, link capabilities and the TSN network topology information. For example, if the first TSN end station110desires to send class X data traffic to the second TSN end station112, the CNC102will calculate the end-to-end path and configure the corresponding TSN nodes to support such data session.

FIG. 2illustrates a block diagram of a TSN200, in accordance with some embodiments of the invention. The TSN200includes a CNC202, at least portions of a 5G system204which functions a virtual TSN bridge, a TSN end station206and a TSN entity208, which can be another TSN bridge or end station, for example. The CNC202, TSN end station206and TSN entity208can be similar to corresponding nodes described above and, therefore, their descriptions are not repeated here.

As shown inFIG. 2, the 5G system204includes various nodes to provide a virtual or logical TSN bridge. This logical TSN bridge includes TSN Translator (TT) functionality that allows for interoperation between the TSN system and 5G system both for the user plane, implemented by an enhanced user plane function node with TT functionality (UPF/TT)210, and the control plane, implemented by an enhanced application function node with TT functionality (AF/TT) node212. The virtual TSN bridge204further includes a policy control function (PCF) node214, a session management function (SMF) node216, an access and mobility management function (AMF) node218, a next generation radio access network (NG-RAN) node220(e.g., a gNB or ng-eNB base station) and an enhanced user equipment node with TT functionality (UE/TT)222. In some embodiments, the UE/TT node222is a remote device or terminal, separate from the TSN end station206, that is communicatively coupled to the TSN end station206and communicatively coupled to the NG-RAN node220. As used herein, “communicatively coupled” means capable of communicating data or information by any known means such as electromagnetic wireless communication technologies, wired communication technologies, fiber optic communication technologies, etc. In alternative embodiments, the UE/TT node222may be a device or circuit (RF circuit, SIM card, etc.) that is part the TSN end station206and communicatively coupled to the NG-RAN node220. Conventional functions of each of the nodes210-222, known in the art, are not described herein.

In some embodiments, the 5G System specific procedures in the 5G core network (5GC) and NG-RAN, wireless communication links, etc., remain hidden from the TSN network. Thus, from the perspective of the TSN200, the 5G system204is viewed as a physical TSN bridge. To achieve transparency to the TSN200, the 5G system204provides TSN ingress and egress ports via the UE/TT node222on UE side and via the UPF/TT node210and AF/TT node212on the 5GC side towards the TSN network, which includes the CNC202and TSN entity208. In some embodiments, for one particular TSN network, the virtual TSN bridge204is defined on a per UPF granularity basis, which means all PDU sessions for the particular TSN network processed by the same UPF/TT node210will define one virtual TSN bridge having a TSN bridge ID. In some embodiments, it is possible that multiple TSN networks are communicatively coupled to the same port of the UPF/TT node210and the AF/TT node212of a 5G system204. In such a scenario, the 5G system204can function as multiple virtual TSN bridges, each virtual TSN bridge acting as bridge for a respective one of the multiple TSN networks.

FIG. 3illustrates a block diagram of a 5G system300that functions as two virtual TSN bridges for two TSN networks, TSN network-1 and TSN network-2, respectively, in accordance with some embodiments. The first TSN network includes a first CNC302, a first TSN network entity304on the user plane side, a first TSN end station306, a second TSN end station308, a third TSN end station310and fourth TSN end station312. The second TSN network consists of a second CNC314, a second TSN entity316on the user plane side, a fifth TSN end station318and a sixth TSN end station320. As shown inFIG. 3, the 5G system300further includes a UPF/TT node322, a AF/TT node324, a PCF node326, a SMF node328, an AMF node330and a NG-RAN node332(e.g., gNB or ng-eNB node). The functions of nodes302-332are similar to the corresponding functions described above and are not repeated here.

To function as a virtual TSN bridge for the first TSN network, the 5G system300further includes first, second, third and fourth UE/TT nodes,334,336,338and340, respectively, that provide UE/TT functionality to the first, second, third and fourth end stations306,308,310and312, respectively. To function as a virtual TSN bridge for the second TSN network, the 5G system300includes a fifth UE/TT node342that provides UE/TT functionality to the sixth TSN end station320. As shown inFIG. 3, the fourth UE/TT node340can also provide UE/TT functionality to the fifth TSN end station318. Thus, the fourth UE/TT node340can be shared by TSN end stations312and318, which belong to different TSN networks, in accordance with some embodiments.

Thus, from the perspective of the first TSN network, the 5G system300provides a first TSN bridge with a first Bridge ID (e.g., a value that identifies the first virtual TSN bridge). From the perspective of the second TSN network, the 5G system300provides a second TSN bridge with a second Bridge ID. In some embodiments, the first and second Bridge IDs can either be the same or different. Since the first and second TSN networks are different TSN networks, the 5G system300can use the same or different Bridge ID for both TSN networks.

However, within one virtual TSN bridge, as seen by one TSN network, each physical port has a unique port number, in accordance with some embodiments.FIG. 4illustrates a first virtual bridge300-1provided by the 5G system300(FIG. 3) from the perspective of the first TSN network comprising TSN entities302-312. As shown inFIG. 4, each of the physical ports communicatively coupled to the TSN entities304-312of the first TSN network has a unique port number (port 0, port 1, port 2, port 3 and port 4).

FIG. 5illustrates a block diagram of a second virtual TSN bridge300-2provided by the 5G system300(FIG. 3) from the perspective of the second TSN network that includes TSN entities314-320. As shown inFIG. 5, similar toFIG. 4, each of the physical ports communicatively coupled to the TSN entities316-320of the second TSN network has a unique port number (port 0, port 1 and port 2) as seen from the perspective of the second TSN network. Note, however, the physical ports servicing the second TSN network can have the same port numbers (port 0, port 1 and port 2) as physical ports servicing the first TSN network. This is because PDU sessions for different TSN networks can be differentiated from each other by the UPF/TT322since the 5G system300knows the relationships between PDU sessions and the TSN networks. For example, referring again toFIG. 3, the UPF/TT node322connects to both the first and second TSN network entities304and316, respectively, using different physical ports, with the same port number (port 0).

As described above, keeping track of Bridge ID's and port numbers can be complex, especially if a 5G system serves as virtual TSN bridge for a large number of TSN networks. Therefore, in order to implement the above-described virtual TSN bridge functions, a unique port number allocation protocol is required in the enhanced 5G system300and the UE/TT nodes222(FIG. 2) and334-342(FIG. 3) are required to know the Bridge ID and respective unique port numbers for each virtual TSN bridge to perform neighborhood topology discovery, for example.

In accordance with some embodiments, a method for PDU session establishment in a TSN network includes the following operations: the UPF/TT node allocates a bridge port number for the PDU session and sends it to the SMF node when the UE/TT node requests a PDU session to be established; the SMF node then sends the allocated bridge port number to the UE node. Optionally, in some embodiments, in addition to the bridge port number, the SMF may send Bridge Information (e.g., a Bridge ID and/or TSN network information) corresponding to the bridge port number to UE/TT node in order to establish the PDU session.

In further embodiments, the SMF may send TSN network information to the UPF/TT node in N4 session request and the UPF/TT will respond with the allocated bridge port number. As a further option, in some embodiments, the SMF may send information associated with multiple TSN networks to the UPF in a N4 session request and the UPF/TT will respond with an allocated bridge port number for every TSN network. Note, when the UPF/TT connects to multiple TSN networks, for each TSN network, the UPF/TT looks like a TSN bridge. In further embodiments, the SMF may send multiple set of bridge port numbers and/or Bridge Information) to the UE/TT. The Bridge Information may include a Bridge ID and/or TSN network information, which may include a TSN domain number, for example.

FIG. 6illustrates a signaling protocol for a method of PDU session establishment by a virtual TSN bridge, in accordance with some embodiments of the invention. The network entities shown inFIG. 6(e.g., AMF, SMF, UPF/TT, etc.) correspond to the same types of network entities described above. Additionally, a unified data management (UDM) node is shown, which is known in the art. For purposes of clarity, unrelated network entities and steps are not shown inFIG. 6.

At operation601, the UE/TT sends a PDU session establishment Request to the AMF. Next, at operation602, the AMF invokes a Nsmf_PDUSession_CreateSMContext service operation towards the SMF. At operation603, the SMF retrieves the UE SM subscription data from the UDM node. At operation604, if the SMF is able to process the PDU Session establishment request, the SMF creates a session management (SM) context and responds to the AMF by providing an SM Context ID. Next, at operation605, the SMF sends a N4 session request to the UPF/TT. Optionally, in operation605, the SMF can include the TSN network information in the N4 session request sent to the UPF/TT. If the UE/TT can access multiple TSN networks and/or the UPF/TT connects to multiple TSN networks, the SMF can include the TSN network information for each TSN network in the message.

Next, at operation606, the UPF/TT acknowledges receipt of the N4 session request by sending an N4 session response to the SMF, which includes the allocated bridge port number for the PDU session. Optionally, the N4 session response can further include a Bridge ID for the TSN network. If UPF/TT receives information for multiple TSN networks, the N4 session response message can include a bridge port number for the PDU session and/or Bridge ID for each TSN network. At operation607, the SMF invokes a Namf_Communication_N1N2 Message Transfer to the AMF, which includes the N2 SM information and N1 SM container. It also includes Bridge Port information. The Bridge Port information includes the Bridge ID and Bridge Port number. Optionally, the TSN network information related to the Bridge is included. If the UPF/TT allocates Bridge Port numbers for multiple virtual bridges, multiple (Bridge ID, Bridge Port number, TSN network information) sets are included in the Bridge Port information. The Bridge Port information may be included in the N1 SM container, or in a standalone Information Element (IE).

At operation608, the AMF sends a N2 PDU Session Request to the NG-RAN node, which includes an N1 SM container and the Bridge Port information. The Bridge Port information may be included in the N1 SM container, or in a standalone IE. Finally, at operation609, the NG-RAN uses the time and Quality of Service (QoS) information in the N2 SM information for radio resource establishment and sends the N1 SM container and Bridge Port information to the UE/TT node in the Radio Resource Control (RRC) signaling to accept the PDU session establishment. In some embodiments, the Bridge Port information may be included in the N1 SM container, or in a standalone IE.

In alternative embodiments, a method of PDU session establishment can implement the following operations: the SMF allocates the bridge port number and sends it to the UE/TT when the UE/TT requests a PDU session to be established. In some embodiments, the UPF may send a Bridge port number range to the SMF. Then the SMF allocates the Bridge port number according to the range. Further, in some embodiments, when the UPF/TT connect to multiple TSN networks, it may send a Bridge port number range for every virtual TSN Bridge to the SMF. Note, in this case, the UPF/TT functions to provide multiple TSN bridges. In some embodiments, in addition to bridge port number, the SMF may send Bridge information (e,g Bridge ID and/or TSN network information) corresponding to the bridge port number to UE/TT during the PDU session establishment. Optionally, the SMF may send multiple (Bridge port number and/or Bridge information) sets for respective ones of multiple TSN networks to the UE/TT node. In accordance with some embodiments, the Bridge information may be Bridge ID and/or TSN network information, and the TSN network information may include a TSN domain number.

FIG. 7illustrates a signaling protocol for a method of PDU session establishment by a virtual TSN bridge, in accordance with further embodiments of the invention. The network entities shown inFIG. 7(e.g., AMF, SMF, UPF/TT, etc.) correspond to the same types of network entities described above. For purposes of clarity, unrelated network entities and steps are not shown inFIG. 7.

At operation701, the UPF/TT sends bridge port information to the SMF. In some embodiments, the bridge port information includes a port number range for one virtual TSN bridge. The SMF can then allocate port number within the range for a PDU session utilizing the TSN bridge. Thus, if UPF/TT is controlled by multiple SMFs, each SMF will not assign overlapping port numbers with one another if the port number ranges allocated to each SMF do not overlap with each other. When the UPF connects with multiple TSN network, i.e. 5GS act as virtual TSN Bridge for every TSN network, the UPF/TT sends to the SMF the Bridge port information of the virtual bridge for every TSN network. The bridge port information can include TSN network information, Bridge ID, port range, etc.

Next, at operation702, the UE/TT sends a PDU Session establishment Request to the AMF. At operation703, the AMF invokes an Nsmf_PDUSession_CreateSMContext service operation towards SMF. At operation704, the SMF retrieves the UE SM subscription data from the UDM. At operation705, if the SMF is able to process the PDU Session establishment request, the SMF creates an SM context and responds to the AMF by providing an SM Context ID. Next, at operation706, the SMF sends an N4 session request to the UPF/TT. At operation707, the UPF acknowledges by sending an N4 Session Response back to the SMF. At operation708, the SMF allocates a bridge port number for the PDU session and invokes Namf_Communication_N1N2MessageTransfer to the AMF, which includes the N2 SM information, N1 SM container and Bridge Port information. The Bridge Port information includes Bridge ID and Bridge Port number. Optionally, TSN network information related to the Bridge is included. If the UE/TT can access multiple TSN networks and SMF has obtained the Bridge information for these TSN networks, the SMF allocates a bridge port number for every virtual bridge for each of the multiple TSN networks. Further, if the SMF allocates a bridge port number for multiple virtual bridges, in some embodiments, sets of (Bridge ID, bridge port number, TSN network information) information for respective ones of the multiple virtual bridges is included as bridge port information. The bridge port information may be included in the N1 SM container, or in a standalone IE. At operation709, the AMF sends to the NG-RAN node an N2 PDU Session Request, which includes an N1 SM container and the bridge port information. The bridge port information may be included in the N1 SM container, or in a standalone IE. Finally, in operation710, the NG-RAN node uses the time and Qos information in the N2 SM information for radio resource establishment and sends the N1 SM container and bridge port information to the UE/TT in the RRC signaling to accept the PDU session establishment. In accordance with various embodiments, the bridge port information may be included in the N1 SM container, or in a standalone IE.

FIG. 8illustrates a block diagram of a network node800of a wireless system, in accordance with some embodiments of the present disclosure. The network node800is an example of a network node that can be configured to implement the various methods described herein. As shown inFIG. 8, the network node800includes a system clock802, a processor804, a memory806, a power module808, a transceiver810comprising a transmitter812and receiver814, and a system bus820, all contained in a housing830. The network node800further includes at least one antenna840coupled to the transceiver810and attached to the housing830.

In this embodiment, the system clock802provides the timing signals to the processor704for controlling the timing of all operations of the network node700. The processor704controls the general operation of the network node700and can include one or more processing circuits or modules such as a central processing unit (CPU) and/or any combination of general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate array (FPGAs), programmable logic devices (PLDs), controllers, state machines, gated logic, discrete hardware components, dedicated hardware finite state machines, or any other suitable circuits, devices and/or structures that can perform calculations or other manipulations of data.

The memory806, which can include both read-only memory (ROM) and random access memory (RAM), can provide instructions and data to the processor804. A portion of the memory806can also include non-volatile random access memory (NVRAM). The processor804typically performs logical and arithmetic operations based on program instructions stored within the memory806. The instructions (a.k.a., software) stored in the memory806can be executed by the processor804to perform the methods described herein. The processor804and memory706together form a processing system that stores and executes software. As used herein, “software” means any type of instructions, whether referred to as software, firmware, middleware, microcode, etc. which can configure a machine or device to perform one or more desired functions or processes. Instructions can include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the one or more processors, cause the processing system to perform the various functions described herein.

The transceiver810, which includes the transmitter812and receiver814, allows the network node800to transmit and receive data to and from a remote device (e.g., another network node). The antenna840is typically attached to the housing830and electrically coupled to the transceiver810. In various embodiments, the network node800includes (not shown) multiple transmitters, multiple receivers, and multiple transceivers. In one embodiment, the antenna840includes a multi-antenna array that can form a plurality of beams each of which points in a distinct direction. The transmitter812can be configured to wirelessly transmit packets having different packet types or functions, such packets being generated by the processor804. Similarly, the receiver814is configured to receive packets having different packet types or functions, and the processor804is configured to process packets of a plurality of different packet types. For example, the processor804can be configured to determine the type of packet and to process the packet and/or fields of the packet accordingly.

According to various embodiments, the network node800may be configured to perform the function of any one of the network nodes illustrated inFIGS. 1-7and described above. For example, the network node800may be configured to perform the functions of the UPF/TT node, a SMF node, an AMF node, or a UE/TT node, as described above.

The power module808can include a power source such as one or more batteries, and a power regulator, to provide regulated power to each of the above-described modules inFIG. 7. In some embodiments, if the network node800is coupled to a dedicated external power source (e.g., a wall electrical outlet), and the power module808can include a transformer and a power regulator.

The various modules discussed above are coupled together by the bus system820. The bus system820can include a data bus and, for example, a power bus, a control signal bus, and/or a status signal bus in addition to the data bus. It is understood that the modules of the network node800can be operatively coupled to one another using any suitable techniques and mediums.

Although a number of separate modules or components are illustrated inFIG. 8, persons of ordinary skill in the art will understand that a single module can be divided into multiple modules or a plurality of modules can be combined or commonly implemented. For example, the processor804can implemented either as a single module or as a plurality of modules to perform the various functions described herein.

A person of ordinary skill in the art would further appreciate that any of the various illustrative logical blocks, modules, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two), firmware, various forms of program or design code incorporating instructions (which can be referred to herein, for convenience, as “software” or a “software module), or any combination of these techniques.

To clearly illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware or software, or a combination of these techniques, depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in various ways for each particular application, but such implementation decisions do not cause a departure from the scope of the present disclosure. In accordance with various embodiments, a processor, device, component, circuit, structure, machine, module, etc. can be configured to perform one or more of the functions described herein. The term “configured to” or “configured for” as used herein with respect to a specified operation or function refers to a processor, device, component, circuit, structure, machine, module, etc. that is physically constructed, programmed and/or arranged to perform the specified operation or function.