TECHNICAL FIELD

[0001] This description relates to wireless communications.

BACKGROUND

[0002] A communication system may be a facility that enables communication between two or more nodes or devices, such as fixed or mobile communication devices. Signals can be carried on wired or wireless carriers.

[0003] An example of a cellular communication system is an architecture that is being standardized by the 3 ^rd Generation Partnership Project (3 GPP). A recent development in this field is often referred to as the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology. E- UTRA (evolved UMTS Terrestrial Radio Access) is the air interface of 3GPP's Long Term Evolution (LTE) upgrade path for mobile networks. In LTE, base stations or access points (APs), which are referred to as enhanced Node AP (eNBs), provide wireless access within a coverage area or cell. In LTE, mobile devices, or mobile stations are referred to as user equipments (UE). LTE has included a number of improvements or developments. Aspects of LTE are also continuing to improve.

[0004] 5G New Radio (NR) development is part of a continued mobile broadband evolution process to meet the requirements of 5G, similar to earlier evolution of 3G & 4G wireless networks. 5G is also targeted at the new emerging use cases in addition to mobile broadband. A goal of 5 G is to provide significant improvement in wireless performance, which may include new levels of data rate, latency, reliability, and security. 5G NR may also scale to efficiently connect the massive Internet of Things (IoT) and may offer new types of mission-critical services. For example, ultra-reliable and low- latency communications (URLLC) devices may require high reliability and very low latency.

SUMMARY

[0005] According to an example embodiment, a method may include receiving, by a user equipment from a base station, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more radio resources allocated for Idle state transmission of data for the application; and transmitting data for the application, by the user equipment to the base station via at least one of the one or more radio resources while the user equipment is in Idle state, wherein the application for the data is indicated based on either an application-specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data.

[0006] According to an example embodiment, an apparatus may include means for receiving, by a user equipment from a base station, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more radio resources allocated for Idle state transmission of data for the application; and means for transmitting data for the application, by the user equipment to the base station via at least one of the one or more radio resources while the user equipment is in Idle state, wherein the application for the data is indicated based on either an application-specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data.

[0007] According to an example embodiment, an apparatus may include: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to receive, by a user equipment from a base station, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more radio resources allocated for Idle state transmission of data for the application; and transmit data for the application, by the user equipment to the base station via at least one of the one or more radio resources while the user equipment is in Idle state, wherein the application for the data is indicated based on either an application- specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data.

[0008] According to an example embodiment, a non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by at least one processor, are configured to cause a computing system to perform a method of: receiving, by a user equipment from a base station, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more radio resources allocated for Idle state transmission of data for the application; and transmitting data for the application, by the user equipment to the base station via at least one of the one or more radio resources while the user equipment is in Idle state, wherein the application for the data is indicated based on either an application-specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data.

[0009] According to an example embodiment, a method may include transmitting, by a base station, information that includes at least application information for a first application, the application information for the first application including at least an application identifier that identifies the first application, and information indicating one or more radio resources allocated for use by one or more user equipments in Idle state to transmit data for the first application to the base station; determining, by the base station, an application server associated with the first application; receiving, by the base station from a first user equipment via at least one of the one or more radio resources while the first user equipment is in Idle state, data of the first application, wherein the first application is indicated by the received data based on either an application-specific radio resource via which the data is received or based on an application identifier that is included within the received data; and forwarding the received data of the first application to the application server associated with the first application.

[0010] According to an example embodiment, an apparatus may include means for transmitting, by a base station, information that includes at least application information for a first application, the application information for the first application including at least an application identifier that identifies the first application, and information indicating one or more radio resources allocated for use by one or more user equipments in Idle state to transmit data for the first application to the base station; means for determining, by the base station, an application server associated with the first application; means for receiving, by the base station from a first user equipment via at least one of the one or more radio resources while the first user equipment is in Idle state, data of the first application, wherein the first application is indicated by the received data based on either an application-specific radio resource via which the data is received or based on an application identifier that is included within the received data; and means for forwarding the received data of the first application to the application server associated with the first application.

[0011] According to an example embodiment, an apparatus may include: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to transmit, by a base station, information that includes at least application information for a first application, the application information for the first application including at least an application identifier that identifies the first application, and information indicating one or more radio resources allocated for use by one or more user equipments in Idle state to transmit data for the first application to the base station; determine, by the base station, an application server associated with the first application; receive, by the base station from a first user equipment via at least one of the one or more radio resources while the first user equipment is in Idle state, data of the first application, wherein the first application is indicated by the received data based on either an application-specific radio resource via which the data is received or based on an application identifier that is included within the received data; and forward the received data of the first application to the application server associated with the first application.

[0012] According to an example embodiment, a non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by at least one processor, are configured to cause a computing system to perform a method of: transmitting, by a base station, information that includes at least application information for a first application, the application information for the first application including at least an application identifier that identifies the first application, and information indicating one or more radio resources allocated for use by one or more user equipments in Idle state to transmit data for the first application to the base station; determining, by the base station, an application server associated with the first application; receiving, by the base station from a first user equipment via at least one of the one or more radio resources while the first user equipment is in Idle state, data of the first application, wherein the first application is indicated by the received data based on either an application-specific radio resource via which the data is received or based on an application identifier that is included within the received data; and forwarding the received data of the first application to the application server associated with the first application.

[0013] The details of one or more examples of embodiments are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a block diagram of a wireless network according to an example embodiment.

[0015] FIG. 2 is a diagram of a system according to an example embodiment.

[0016] FIG. 3 is a diagram illustrating operations of a 4-step random access

(RACH) procedure according to an example embodiment.

[0017] FIG. 4 is a diagram illustrating operations of a 2-step random access (RACH) procedure according to an example embodiment.

[0018] FIG. 5 is a diagram illustrating three radio resource control (RRC) states for a UE according to an illustrative example embodiment.

[0019] FIG. 6 is a diagram illustrating operation of a system according to an example embodiment.

[0020] FIG. 7 is a diagram illustrating a broadcasting of application specific system information according to an example embodiment.

[0021] FIG. 8 is a diagram illustrating a UE initiated application registration procedure according to an example embodiment.

[0022] FIG. 9 is a diagram illustrating an application server initiated application registration procedure according to an example embodiment.

[0023] FIG. 10 is a diagram illustrating Idle state data transmission (I-SDT) via 2- step random access procedure and a 4-step random access procedure according to an example embodiment.

[0024] FIG. 11 is a flow chart illustrating operation of a user equipment (UE) according to an example embodiment.

[0025] FIG. 12 is a flow chart illustrating operation of a base station or gNB according to an example embodiment.

[0026] FIG. 13 is a block diagram of a wireless station (e.g., AP, BS, RAN node, UE or user device, or other network node) according to an example embodiment. DETAILED DESCRIPTION

[0027] FIG. 1 is a block diagram of a wireless network 130 according to an example embodiment. In the wireless network 130 of FIG. 1, user devices 131, 132, 133 and 135, which may also be referred to as mobile stations (MSs) or user equipment (UEs), may be connected (and in communication) with a base station (BS) 134, which may also be referred to as an access point (AP), an enhanced Node B (eNB), a BS, next generation Node B (gNB), a next generation enhanced Node B (ng-eNB), or a network node. The terms user device and user equipment (UE) may be used interchangeably. A BS may also include or may be referred to as a RAN (radio access network) node, and may include a portion of a BS or a portion of a RAN node, such as (e.g., such as a centralized unit (CU) and/or a distributed unit (DU) in the case of a split BS). At least part of the functionalities of a BS (e.g., access point (AP), base station (BS) or (e)Node B (eNB), BS, RAN node) may also be carried out by any node, server or host which may be operably coupled to a transceiver, such as a remote radio head. BS (or AP) 134 provides wireless coverage within a cell 136, including to user devices (or UEs) 131, 132, 133 and 135. Although only four user devices (or UEs) are shown as being connected or attached to BS 134, any number of user devices may be provided. BS 134 is also connected to a core network 150 via a SI interface or NG interface 151. This is merely one simple example of a wireless network, and others may be used.

[0028] A base station (e.g., such as BS 134) is an example of a radio access network (RAN) node within a wireless network. A BS (or a RAN node) may be or may include (or may alternatively be referred to as), e.g., an access point (AP), a gNB, an eNB, or portion thereof (such as a centralized unit (CU) and/or a distributed unit (DU) in the case of a split BS or split gNB), or other network node.

[0029] According to an illustrative example, a BS node (e.g., BS, eNB, gNB, CU/DU, ...) or a radio access network (RAN) may be part of a mobile telecommunication system. A RAN (radio access network) may include one or more BSs or RAN nodes that implement a radio access technology, e.g., to allow one or more UEs to have access to a network or core network. Thus, for example, the RAN (RAN nodes, such as BSs or gNBs) may reside between one or more user devices or UEs and a core network. According to an example embodiment, each RAN node (e.g., BS, eNB, gNB, CU/DU, ...) or BS may provide one or more wireless communication services for one or more UEs or user devices, e.g., to allow the UEs to have wireless access to a network, via the RAN node. Each RAN node or BS may perform or provide wireless communication services, e.g., such as allowing UEs or user devices to establish a wireless connection to the RAN node, and sending data to and/or receiving data from one or more of the UEs. For example, after establishing a connection to a UE, a RAN node (e.g., BS, eNB, gNB, CU/DU, ...) may forward data to the UE that is received from a network or the core network, and/or forward data received from the UE to the network or core network.

RAN nodes (e.g., BS, eNB, gNB, CU/DU, ...) may perform a wide variety of other wireless functions or services, e.g., such as broadcasting control information (e.g., such as system information) to UEs, paging UEs when there is data to be delivered to the UE, assisting in handover of a UE between cells, scheduling of resources for uplink data transmission from the UE(s) and downlink data transmission to UE(s), sending control information to configure one or more UEs, and the like. These are a few examples of one or more functions that a RAN node or BS may perform. A base station may also be DU (Distributed Unit) part of IAB (Integrated Access and Backhaul) node (a.k.a. a relay node). DU facilitates the access link connection(s) for an IAB node.

[0030] A user device (user terminal, user equipment (UE), mobile terminal, handheld wireless device, etc.) may refer to a portable computing device that includes wireless mobile communication devices operating either with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (MS), a mobile phone, a cell phone, a smartphone, a personal digital assistant (PDA), a handset, a device using a wireless modem (alarm or measurement device, etc.), a laptop and/or touch screen computer, a tablet, a phablet, a game console, a notebook, a vehicle, a sensor, and a multimedia device, as examples, or any other wireless device. It should be appreciated that a user device may also be (or may include) a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A user device may be also MT (Mobile Termination) part of IAB (Integrated Access and Backhaul) node (a.k.a. a relay node).

MT facilitates the backhaul connection for an IAB node.

[0031] In LTE (as an illustrative example), core network 150 may be referred to as Evolved Packet Core (EPC), which may include a mobility management entity (MME) which may handle or assist with mobility/handover of user devices between BSs, one or more gateways that may forward data and control signals between the BSs and packet data networks or the Internet, and other control functions or blocks. Other types of wireless networks, such as 5G (which may be referred to as New Radio (NR)) may also include a core network.

[0032] In addition, by way of illustrative example, the various example embodiments or techniques described herein may be applied to various types of user devices or data service types, or may apply to user devices that may have multiple applications running thereon that may be of different data service types. New Radio (5G) development may support a number of different applications or a number of different data service types, such as for example: machine type communications (MTC), enhanced machine type communication (eMTC), Internet of Things (IoT), and/or narrowband IoT user devices, enhanced mobile broadband (eMBB), and ultra-reliable and low-latency communications (URLLC). Many of these new 5G (NR) - related applications may require generally higher performance than previous wireless networks.

[0033] IoT may refer to an ever-growing group of objects that may have Internet or network connectivity, so that these objects may send information to and receive information from other network devices. For example, many sensor type applications or devices may monitor a physical condition or a status, and may send a report to a server or other network device, e.g., when an event occurs. Machine Type Communications (MTC, or Machine to Machine communications) may, for example, be characterized by fully automatic data generation, exchange, processing and actuation among intelligent machines, with or without intervention of humans. Enhanced mobile broadband (eMBB) may support much higher data rates than currently available in LTE. [0034] Ultra-reliable and low-latency communications (URLLC) is a new data service type, or new usage scenario, which may be supported for New Radio (5G) systems. This enables emerging new applications and services, such as industrial automations, autonomous driving, vehicular safety, e-health services, and so on. 3GPP targets in providing connectivity with reliability corresponding to block error rate (BLER) of 10 ⁵ and up to 1 ms U-Plane (user/data plane) latency, by way of illustrative example. Thus, for example, URLLC user devices/UEs may require a significantly lower block error rate than other types of user devices/UEs as well as low latency (with or without requirement for simultaneous high reliability). Thus, for example, a URLLC UE (or URLLC application on a UE) may require much shorter latency, as compared to a eMBB UE (or an eMBB application running on a UE).

[0035] The various example embodiments may be applied to a wide variety of wireless technologies or wireless networks, such as LTE, LTE-A, 5G (New Radio (NR)), cmWave, and/or mmWave band networks, IoT, MTC, eMTC, eMBB, URLLC, etc., or any other wireless network or wireless technology. These example networks, technologies or data service types are provided only as illustrative examples.

[0036] PIG. 2 is a diagram of a system according to an example embodiment. According to an illustrative example, PIG. 2 may illustrate an Internet of Things (IoT) scenario, in which an IoT gateway (in this non-limiting example implemented by a 5G gNB/BS 210) controls a number of IoT devices (in this non-limiting example implemented by 5G user equipment’s (UEs)) via the NR (new radio)/5G wireless interface, providing them connectivity towards the Internet 220. Thus, as shown in PIG. 2, gNB 210 (e.g., operating as an IoT gateway, providing UEs/IoT device or applications with Internet connectivity) may be in communication with and/or provided wireless services for a large number of UEs, where each UE may be an IoT device that may transmit UL data for one or more applications. For example, UE 212 may generate and transmit data for application A, and UE 214 may generate and transmit data for application B. According to an illustrative example, an application server may be provided for each application, including an application server 230 for application A, and an application server 232 for application B.

[0037] Thus, according to an illustrative example embodiment shown in FIG. 2, uplink (UL) small payload transmissions are generated by the IoT devices (e.g., UEs 212, 214, ...) with very sporadic patterns (e.g., such as on the order of a few messages per day, not typically in bursts). Also, to maximize the battery lifespan, the IoT devices will go to sleep mode after the end of each UL data transmission (e.g., Idle state). If privacy/security is required, over-the-top (OTT) (e.g., application-level) encryption may be applied to the UL payload at the application layer between each IoT device and the application server. It is noted that 3GPP assumes OTT encryption in 5G networks e.g. in phase 1 , in which the support of radio user plane integrity is mandatory at the NW but optional to use by 5G UEs. If required by the application, positioning information and/or IoT device identifier (ID) may be embedded in the UL payload by the application layer.

In this illustrative example, the UEs in FIG. 2 may be grouped in two sets, where each set is assumed to request a distinct application, namely Application A or Application B, which may be terminated to a different server, namely server 230 for application A or server 232 for application B. Here, the gNB 210 (acting as an IoT gateway) is in charge of forwarding the packets/data received from the UEs to the intended application server. The illustrative system shown in FIG. 2 is merely provided as an illustrative example embodiment, and other systems, configurations and different numbers of UEs and servers may be used or provided.

[0038] It is expected that in the coming years a massive number of IoT type UEs (or other UEs or wireless devices) will be deployed across 5G/ NR networks (or other wireless networks). According to an example embodiment, at least in some cases, these type of UEs may be characterized by the need to sporadically transmit small payloads with very low power consumption. To this end, it may be advantageous or desirable that these devices or UEs do not spend too much time in RRC CONNECTED state to maximize their battery life. Rather, according to an example embodiment, these UEs should be moved to more energy-efficient RRC states (e.g., RRC Idle / RRC Inactive). Furthermore, the RRC CONNECTED state should be avoided as much as possible also from a network point of view, to prevent an excessive consumption of both radio resources at RAN (radio access network/gNB) and Core Network (CN) resources including CN signalling due to UE mobility. For instance, control channel bottlenecks may appear in presence of a massive number of active UEs, e.g., in terms of PUCCH (physical uplink control channel) resources. Similarly, the supported number of simultaneous RRC connections may not be sufficient to satisfy a huge number of UEs or IoT devices. Thus, according to an example embodiment, the network may advantageously support small data transmission from Idle state or Inactive state UEs or devices.

[0039] However, according to current 5G specifications, when a payload (data traffic) is generated, the UEs in RRC Idle and Inactive should switch to RRC CONNECTED before proceeding with the data transmission. The RRC state switching from RRC Idle entails heavy signalling traffic, hence associated access delay and battery drainage to setup RAN/CN user-plane (UP) connectivity, including the radio security contexts. A state transition from RRC Inactive allows to shorten significantly the switching time, however it requires that a UE has to be in RRC Connected state first to store its AS (security) Context to be used afterwards at the connection resume. For massive IoT scenarios, this may result in having thousands of UEs switching to RRC Connected mode, thus causing large signalling overhead, which is undesirable.

[0040] Therefore, according to an example embodiment, various techniques or embodiments are provided, for example, for (or to support) relatively small data transmission (less than a threshold) for UEs in an Idle state (e.g., RRC Idle), without requiring a UE transition to a Connected state, which may, e.g., reduce signalling overhead, improve UE transmission efficiency or speed, and improve UE battery life and/or reduce UE power consumption, for example.

[0041] Various example embodiments may relate to transmission of application data from a UE to a gNB. The gNB may then forward the application data to a server (e.g., application server). Some example embodiments may relate to or describe techniques that allow for an Idle state UE to transmit a relatively small (or limited) amount of application data to a gNB via radio resources that have been allocated for use by a UE in Idle or Inactive state to transmit data for the application, without requiring the UE to first establish a connection (or transition to a Connected state). For example, some example embodiments may support massive IoT scenarios in 5G/New Radio (5G/NR) systems, particularly to the support of small data transmission in RRC (radio resource control) Idle state, e.g., without first requiring the UE to transition to RRC Connected state, which may save time and power for the UE (e.g., allowing faster Idle state transmissions, and while using less battery power). In some example embodiments, random access procedure (RACH) resources may be allocated for one or more applications (or allocated for a group of applications), e.g., for Idle UEs to transmit relatively small amounts of data, e.g., via message A of a 2-step RACH procedure, or via message 3 of a 4-step RACH procedure, by way of illustrative example. In some example embodiments, application-specific radio resources may be allocated for an Idle (e.g., RRC Idle state) UE to transmit uplink (UL) application data for an application to the gNB, where the use of the application-specific resources may identify for which application the data is for (or which application the data is associated with).

Alternatively, radio resources may be provided for a plurality of applications (or otherwise may not uniquely identify an application), and an application identifier (Application ID) may be included within the transmitted data. The gNB may determine the application associated with the received data (e.g., either based on the application- specific resources used for the data transmission and/or based on an application identifier included within the transmitted data), and may forward the application data to an application server for processing. Also, according to an example embodiment, an application may be registered with a gNB/base station, and the gNB may then begin to transmit or broadcast application specific system information, which may include an application ID for the application that is supported and an information indicating one or more radio resources allocated for Idle UL transmission of data for the application. As noted, the radio resources may be, for example, RACH resources (e.g., either one or more RACH preambles, and/or uplink data (e.g., PUSCH) resources) to allow for the UL data transmission for the application. According to an example embodiment, the radio resources may be application-specific time-frequency resources allocated for transmission of data for the application, and not UE-specific resources. Thus, for example, the radio resources may be allocated generally for transmission of application data for the application, and not assigned or allocated to any specific UE. This is in contrast to most other resource allocations (e.g., UL scheduling grants) that are typically UE-specific (assigned by the BS to a specific UE only).

[0042] In another example embodiment, a method may include receiving, by a UE from a BS, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more application-specific radio resources that are non-user equipment-specific, wherein the application-specific radio resources being allocated for transmission of data for the application; and transmitting data for the application, by the UE to the BS via at least one of the one or more application-specific radio resources, wherein the application for the data is indicated based on either an application-specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data. In an example embodiment, the UE (which may be transmitting on the application-specific resources) may be either an Idle state UE, an Inactive state UE, or a Connected state UE. Thus, for example, the UE may be a UE in Idle state (e.g., RRC Idle state); or a UE in either Inactive state (e.g., RRC Inactive state) or Connected State (e.g., RRC Connected state) that behaves or operates (at least in some way) as an Idle state user equipment with respect to the base station for a period of time by the user equipment not transmitting its dedicated radio network identifier assigned by the base station to the user equipment or other context information provided to the user equipment that is in Inactive state or Connected state. Thus, in this example embodiment, the radio resources (e.g., application-specific radio resources allocated for transmission of data of the application) may be used for transmission by either an Inactive UE, or by an Inactive state or a Connected state UE that may operate or present itself to the BS as an Idle state UE, e.g., to the extent such UE does not use the UE- specific context (e.g., UE-specific security context allocated to the UE) and/or cell- specific UE identifier (e.g., C-RNTI) that may have been assigned to the UE, when the UE is transmitting via such application-specific radio resources. Thus, for example, the allocated radio resources may be application-specific radio resources (allocated for transmission of data for the application by any of the UEs), and is not UE-specific like most radio resource (e.g., UL resource allocation of time-frequency resources) allocations. An Inactive UE or a Connected UE may transmit via such allocated resources, e.g., without the UE necessarily providing its cell specific UE identifier (e.g., cell radio network temporary identifier or C-RNTI assigned to the UE) to the BS when transmitting via such resources, and/or without using the context (e.g., security context or other context) that may have been assigned to the UE by the BS. This may allow a faster or more efficient transmission, at least in some cases. Security may be provided at the application level or over the top security for the data transmitted via the allocated radio resources. In this manner, a UE in Idle state, Inactive state, or Connected state may be able to use such application-specific resources for transmission of the application data.

[0043] FIG. 3 is a diagram illustrating operations of a 4-step random access (RACH) procedure according to an example embodiment. When the RACH procedure is triggered (caused to be performed by the UE), the UE sends a random access preamble over the random access channel (RACH) (Step 1), or msgl (message 1). There are different groups of preambles defined, depending on the size of msg3 (message 3) and based on the UE’s channel conditions. The UE obtains information on how to access the channel from system information block 1 (SIB1) broadcasted in the BS system information (SI). In Step 2 (msg2 or message 2), the network (BS), upon reception of a preamble (if there are no collisions with other UEs), responds with a random access response (RAR). The UE must monitor the physical downlink control channel (PDCCH) channel identified by an RA-RNTI (random access-radio network temporary identifier assigned to the UE) during a window that starts at the subframe containing the end of the preamble transmission. Upon receiving the RAR message, the UE can send the first uplink transmission to the network (msg3 or message 3). The size of the transmission of msg3 depends on the grant received at step 2 (msg2 or message 2). Step 4 (msg 4 or message 4) involves the contention resolution phase. After the completion of the 4-step RACH and the UE transmission of the RRC Setup complete message (msg5, not shown), the UE is in RRC CONNECTED mode and can perform a scheduling request. This entails very large access delay (e.g., which may, at least in some cases, be on the order of ~76 ms for a UE in RRC Idle and ~10 ms for a UE in RRC Inactive) due to RRC state transition signalling.

[0044] Furthermore, according to an example embodiment, as an alternative RACH procedure, a 2-step RACH (random access) procedure may be used to provide a faster random access procedure. FIG. 4 is a diagram illustrating operations of a 2-step random access (RACH) procedure according to an example embodiment. At message A (msgA), a UE may transmit msg3 (or a message that include contents of both msgl and msg3) as a first message (msgA) of the 2-step RACH procedure. And, for example, the BS or gNB may transmit msg2 and msg4 as a second message (or msgB or message B) of the 2-step RACH procedure.

[0045] According to an illustrative example embodiment, a relatively small application data (e.g., less than a threshold, such as less than 100 bits, or less than 1000 bits, or other threshold) may be transmitted by the UE in Idle state as a random access procedure (RACH) message. For example, the message may be sent as a message A (msgA) (or a first message sent by the UE to a BS) of a 2-step RACH procedure. Or, the message, including the application data, may be sent, e.g., as a combination of msgl (the first message) and msg3 (the third message) transmitted by the UE to the BS of a 4-step RACH procedure. MsgA of the 2-step RACH procedure may combine or include the information of both msgl and msg3 of the 4-step RACH procedure, for example. Thus, RACH resources may be used by a UE (e.g., IoT device) to transmit a relatively small application data (e.g., RACH transmission in this case is performed to transmit small data, and not for the purpose of establishing a connection or transitioning UE to Connected state). In addition, according to an example embodiment, Idle state or Inactive state UEs may transmit relatively small application (or user plane) data via other radio resources that may be available or may have been allocated by the gNB for this purpose (e.g., for Idle state data transmission to the gNB).

[0046] FIG. 5 is a diagram illustrating three radio resource control (RRC) states for a UE according to an illustrative example embodiment. RRC Idle state 510, in which the UE does not have a dedicated UE identifier (e.g., a dedicated RNTI (radio network temporary identifier) has not been assigned to the UE). RRC Inactive state 512, in which the UE has a dedicated Inactive-RNTI (I-RNTI) and stores the AS (access stratum, including security) context. RRC Connected state 514 in which the UE has a dedicated Cell-RNTI (C-RNTI) and stores the AS context.

[0047] As noted, various example embodiments/techniques described herein may support or enable Idle state-Small Data Transmission (I-SDT) with 2-step or 4-step RACH for UEs in RRC IDLE. According to an example embodiment, the data protection or security (encryption and integrity, if performed) may be performed, e.g., at the application level (which may be referred to as over the top (OTT)) and as such does not require any a-priori establishment of radio security context.

[0048] According to an example embodiment, the technique(s) may enable the UE to wake up from RRC Idle state, transmit its payload using the proposed I-SDT method and go back to its original Idle state, thus entailing minimum (or at least a reduced) signalling and UE power consumption (e.g., as compared to transitioning to a Connected state for data transmission). For example, small data (e.g., less than a threshold size) may be transmitted by an Idle state UE via U1 PUSCH resources, e.g., allocated for UL I-SDT transmission, e.g., via either msg3 of 4-step RACH or msgA of a 2-step RACH, as illustrative examples. These PUSCH radio resources, e.g., allocated by gNB 210 for I-SDT transmission, may be provided for UL transmission for a group or plurality of applications, or may be application-specific.

[0049] FIG. 6 is a diagram illustrating operation of a system according to an example embodiment. Two UEs (UE1, and UE2) may be in communication with gNB 210. An application server 230 may be provided for handling or processing application data that is transmitted by UE1 and UE2). Operations A1 and A2 indicate Registration at the network (e.g., gNB 210) of the intended applications to be supported: the registration takes place at the network (e.g. at the gNB acting as IoT gateway) by acquiring data from the application clients at the UE and/or application servers. At A1 , a registration request is sent by UE1 to gNB 210, while at A2, a registration request is sent by the application server 210 to gNB 210. The registration request may include information relating to or describing the application to be registered, e.g., such as an application identifier that identifies the application and information identifying one or more characteristics of the application, such as, e.g., one or more QoS (quality of service) parameters of the application such as one or more of a size or maximum size of data transmissions for the application, a frequency or periodicity of transmissions for the application, a maximum latency between UL transmissions, or minimum latency between transmissions, or a name or description of the identifier, or other information related to the application.

Thus, as shown, for example, UE1 (or the Application server 230) triggers (causes or requests) the registration of the application A at the gNB 210, and proceeds with the I- SDT (Idle state-small data transmission). UE2 may receive or detect the broadcast application specific system information for application A from gNB 210 (and thus, UE2 is able to detect that application A is supported for Idle state-small data transmission and detects the radio resources that may be used for such I-SDT transmission), and UE2 thus takes advantage of or performs the I-SDT without requiring prior application registration from UE2 for application. Dashed line indicates control plane procedures and continuous line indicates user plane procedures.

[0050] At operation B of FIG. 6, gNB 210 may broadcast information, e.g., application specific system information to enable idle-mode small data transmissions: the application specific information may be broadcast for one or more applications for which idle state small data transmission is supported by the gNB. The broadcast application specific system information may include, e.g., for one or more supported applications, an application identifier, information identifying radio resources allocated for use by a UE in idle state (idle state UEs) to transmit data for the application. For example, the radio resources for the application(s) may include, e.g., application-specific RACH preambles and/or application-specific PUSCH (data) resources associated to the preamble. Also, for example, the application specific system information may include, e.g., additional information, such as one or more of whether a 2-step RACH or 4-step RACH (or both) RACH procedure may be used for the idle state data transmission, a maximum data size for each of the types of data transmission (e.g., 100 bit maximum data size for 2-step RACH transmission via msgA, and 1000 bit maximum data size for a 4-step RACH transmission via msg3), a QoS parameter or performance-related parameter (e.g., a data size, expected size, a frequency or periodicity, maximum latency, and/or other QoS or performance parameter for the application). In an illustrative example embodiment, the application specific system information may be broadcast by gNB 210 via an IoT SIB (IoT system information block), or other SIB or information block.

[0051] Operations Cl and C2of FIG. 6 include user plane (UP) data transmission by a UE in RRC Idle state for a registered application: the UE, having data to transmit for an application A (e.g., associated with application server 230), will use the corresponding radio resources (e.g., RACH preamble and/or PUSCH data resources) as indicated by the received application specific system information broadcasted by the gNB 210, if available. For example, operation Cl may include UE1 transmitting small (e.g., I-SDT) data for application A (e.g., via RACH resources for either 2-step RACH or 4-step RACH procedure, as indicated in the broadcast application specific system information) to gNB 210, while operation C2 may include UE2 transmitting small (e.g., I-SDT) data for application A to gNB 210.

[0052] In FIG. 6, operations D1 and D2 include the gNB 210 forwarding UP (user plane) data of an application via the established CN UP (core network user plane) connectivity towards the corresponding application server. For example, operations D1 and D2 of FIG. 6 may include gNB 210 forwarding of small data received from a UE to an application server associated with the application A. For example, based on a registration request, gNB 210 may determine an application server associated with the application that is being registered (e.g., application server 230 associated with application A). For example, the gNB 210 may determine or establish an application- specific UP communications tunnel or UP connectivity, associated with application A, between gNB 210 and application server 230. According to an illustrative example, a GPRS Tunneling Protocol (GTP) tunnel may be established between the gNB 210 and the application server 230.

[0053] GPRS may include a group of IP (Internet Protocol)-based communications protocols used to carry general packet radio service (GPRS) data within GSM, UMTS and/or LTE networks, and/or NR/5G networks, or other wireless networks. In 3GPP architectures, GTP and Proxy Mobile IPv6 based interfaces are specified on various interface points. GTP can include separate protocols, GTP-C, GTP-U etc. GTP- C may be used within the GPRS core network for signalling between gateway GPRS support nodes (GGSN) and serving GPRS support nodes (SGSN). GTP-U is used for carrying user data within the GPRS core network and between the radio access network (e.g., gNB/BS) and the core network. Thus, for example, in response to a registration request for application A, a GTP-U tunnel (or GTP-U connectivity/connection) may be set up or established between gNB 210 and application server 230, to allow gNB 210 to forward data for application A to application server 230, which is for or associated with application A. Thus, for example, at operation Dl, gNB 210 may forward user plane (UP) data for application A received from UE1 to application server 230 via the application specific communications tunnel or connectivity associated with application A (e.g., a GTP-U tunnel associated with application A). Likewise, at operation D2, gNB 210 may forward user plane data for application A received from UE2 to application server 230 via the same application specific communications tunnel associated with application A. Thus, one (or a shared or common) application server (e.g., server 230) may be provided to receive and process application data from multiple UEs, and one application specific communications tunnel may be established for application A between gNB 210 and the application server 230, according to an illustrative example embodiment. Thus, for example, the communications tunnel (e.g., GTP-U tunnel) is not UE-specific, but is application specific, and may be shared by multiple UEs, to allow the gNB 210 to forward application data received from multiple UEs for an application to the associated application server.

[0054] FIG. 7 is a diagram illustrating a broadcasting of application specific system information according to an example embodiment. At 710, gNB 210 broadcasts application specific system information for one or more I-SDT application. The application specific system information may include, e.g., a list of IoT applications (or applications identifiers or App IDS for each application) that are able to use the proposed I-SDT (for which idle state small data transmission is supported), and an indication of radio resources (e.g., RACH preamble(s) and/or PUSCH resources) that may be used for UL I-SDT transmission of small data by Idle state UEs for each application. The container to convey this application specific system information for one or more I-SDT supported applications may include a new System Information Block (SIB), which may be referred to as IoT SIB (for example), which may be broadcasted periodically with a network configured periodicity.

[0055] According to an example embodiment, the IoT SIB (including application specific system information for one or more applications) may include one or more (or even all) of the following, by way of example:

[0056] 1) An application identifier (e.g., AppID) - A unique application identifier which identifies univocally the IoT application, defined by X bits. The way this identifier becomes known to UE running the IoT application may be or may include the following: a. Pre-reservation - Each IoT application pre -reserves this application identifier and ensures that this application identifier is made part of the UE IoT application initial configuration, such that the UE when decoding the IoT-SIB already knowns which AppID (application identifier) to look for prior to connecting to the network; (e.g., the UE will know in advance the AppID (application identifier) for this application). b. Pooling - A UE upon connecting to the network may (at least in some cases) performs an IoT application registration and as part of this process becomes aware of the AppID (application identifier) to look for in the IoT-SIB; UE initiates registration of the application, and receives the AppID from gNB (gNB may possibly assign AppID to application, and inform UE during application registration); options are for AppID assignment- 1) gNB assigns it; 2) UE could assign the AppID; 3) AppID could be preconfigured by network (maybe part of UE IOT application initial configuration).

[0057] 2) Information identifying radio resources for the application (e.g., application specific resources), or for a group of applications, for which Idle state small data transmission (I-SDT) is supported by the gNB. In an example embodiment, the 2- step or 4-step resources (e.g. PRACH/random access opportunities or specific PRACH/random access preambles in each PRACH opportunity). The definition of these resources for I-SDT can reuse the same structure as the RACH-ConfigDedicated information element. Furthermore, this information element may indicate or inform if the UEs should use 2-step or 4-step as well as any decision threshold (or payload restrictions for different RACH methods) necessary to decide which RACH access method to use (e.g. if payload is greater than x use 2-step RACH for I-SDT transmission, while if data payload is less than or equal to y then use 4-step RACH process for I-SDT transmission). Note, for example, that in some situations, the radio resources for I-SDT may be shared among multiple applications, or may be shared with the normal 2-step/4-step RACH access to establish a connection (or transition the UE to RRC Connected state), but the sharing of these resources may then mean or require that the transmitted payload should include the application identifier or AppID (e.g., since in such case the radio resources used for I-SDT may not be application specific, for the I-SDT transmission).

[0058] According to an example embodiment, the IoT-SIB may indicate RACH preambles or PUSCH resources (for example, each application for which I-SDT is supported by the gNB may have assigned or allocated a different set of application specific RACH preambles and PUSCH resources). Also, for I-SDT transmission, the UE may not have a unique UE Identifier, such as a unique cell-radio network temporary identifier C-RNTI assigned to the UE while in Idle state; even if UE does not have unique identification, the UE can transmit data associated with an application, and gNB/CN would route this application to a specific application server. The resources used for I-SDT transmission may indicate the application, or the application identifier may be included within the I-SDT transmission. Also, a UE identifier may be included within the I-SDT data transmission, which is forwarded by the gNB to the application server.

[0059] Also, according to an example, embodiment, as noted, the network (e.g., gNB) may assign application specific RACH preambles and/or application specific PUSCH resources; If two UEs need to send data for same application A, and they use preamble at the same time, the network or gNB may a detect collision in preamble; Also, to allow a common set of PUSCH resourced for multiple applications, the PUSCH resources may include a set of PRBs (physical resource blocks), e.g., 5 PRBs, and the UE may select a subset of those PRBs/PUSCH resources (e.g., each application may have a unique subset of PUSCH resources assigned for I-SDT transmission) to send its small data while in Idle state. Thus, a different subset of PUSCH resources/P RBs may be allocated for each application for which I-SDT is supported by the gNB.

[0060] According to an example embodiment, a RACH preamble may also be used to identify the UE, to allow time alignment in Uplink; gNB may estimate time alignment in msg2; but where UE is stationary, this new time alignment is not necessary; Thus, in some cases, transmission of a RACH preamble may allow for UE time alignment, and/or allow for easier gNB blind detection of the UE transmitted signal. However, in some cases, the UE may transmit the I-SDT small data via only PUSCH resources, without transmitting a RACH preamble. This is because, the transmission of the I-SDT data via RACH resources is performed to transmit small data while UE is in Idle state, and is not performed to establish a connection or transition the UE to RRC Connected state.

[0061] According to an example embodiment, the IoT-SIB may include application specific information - Limited bit string payload with maximum defined length Y bit, which the contents and format are application specific. This can be used for example to inform or instruct the UEs using the IoT application that they should transition to RRC Connected state and download a firmware update from the gNB. Other examples include load control, where the IoT application controls which information should the IoT UEs report and how often. Or more generally, this field can be used for providing application specific in the downlink direction for example UE specific or group specific acknowledgements.

[0062] Further details on registration of the application in the network: When the IoT UE arrives to the network, as part of its initial access, it listens or detects for the IoT- SIB to check or determine if the UE’s IoT AppID (application identifier) is present (is broadcasted within the IoT-SIB). In case the AppID (application identifier) is not present (or the UE does not know for which AppID to look for, e.g., the pooling approach described above), the UE starts the process to initiate the registration and activation of the I-SDT functionality for IoT application in the network. UE will need a connection (e.g., RRC connection) to gNB to register the application with gNB. According to an example embodiment, application registration for an application may be required to be performed only once at a gNB. Once an application has been registered by a BS/gNB (e.g., based on a request from a UE or an application server), other UEs do not need to repeat registration of that Application, unless the application is removed or dropped by SIB broadcast of the gNB, or UE moves to a new gNB due to mobility. Also, the gNB may have common storage for Application information, to be used across all of its cells (e.g., thus, once an application has been registered by a gNB, the application may be registered for all cells for the gNB, for example). There is also possibility that gNB may relay the application information to neighbour gNBs via Xn interface, e.g., to allow the application information to be received and registered at these neighbour gNBs without requiring a separate application registration to be performed at the neighbour gNB, for example.

[0063] FIG. 8 is a diagram illustrating a UE initiated application registration procedure according to an example embodiment. In this implementation example, the UE transitions to RRC Connected state (e.g., UE1 first establishes a connection to the gNB 210, and the authentication and security context) and then, after transitioning to RRC Connected state with respect to gNB 210, the UE1 sends a registration request to request registration of the IoT Application. The initial access for performing such registration request could be indicated by using a special AppID (e.g. AppID = 0), e.g., a preamble resource associated to it, to indicate a reason or cause for connection is to send an I-SDT or IoT application registration request. This then triggers the gNB 210 (and the associated entities in the Core Network (CN 820)) to contact the application server 230 in order to establish the communication tunnel where the I-SDT UEs payloads will be transmitted through (forwarded by gNB 210 to application server 230 via communications tunnel or connectivity) to the application server 230. After this procedure is completed, the next time the IoT-SIB is broadcasted by the gNB 210 it should include, e.g., the registered AppID for the application and radio resources allocated for I-SDT transmission for the application. Additionally, the gNB 210 may relay the received application information (in the IoT -SIB) to neighbour cells/neighbour gNBs viaX2/Xn (gNB-to-gNB) interface, for example.

[0064] Thus, referring to FIG. 8, at 820, the UE1 receives the IoT-SIB. UE1 detects or determines that the application identifier for the application is not present in the IoT-SIB. This means that the UE1 may register the application with gNB 210 in order, for example, for gNB 210 to provide I-SDT support for the application. Thus, at 822, the UE1 performs initial access (random access procedure) via 2-step or 4-step RACH procedure. At 824, authentication and security context for the connection between UE1 and gNB 210 is established and stored by UE1 and gNB 210. At 826, UE1 sends an application registration request (e.g., which may include an application identifier and information describing one or more characteristics of the application, for example) to the gNB 210 to request registration of the application. At 828, the gNB 210 may forward some registration information for the application (e.g., including an application identifier, and/or one or more application characteristics) to the application server 230. A registration confirmation is provided at 830. At 832, the gNB may activate the I-SDT service or support for the IoT application. This may include allocating radio resources, broadcasting IoT-SIB, and establishing an application specific communications tunnel for the application between the UE1 and the application server 230. At 834, a registration confirmation is sent by the gNB 210 to UE 1.

[0065] FIG. 9 is a diagram illustrating an application server initiated application registration procedure according to an example embodiment. In this implementation example, the registration of the IoT application is triggered from the application server 230. For example, this may be achieved for instance through some core network entities having connections to the external data network. In this setting, all or a fraction of the gNBs (e.g. a tracking area where a given IoT application is expected to be occurring) in the operator network may be configured for the I-SDT with this IoT application. This may include a Control plane communication to set up connectivity for the application. Thus, as shown in FIG. 9, at 910 and 912, application server 230 may send a registration request via core network 810 to gNB 210 to request registration of an IoT application, where the registration request may include an application identifier, and/or one or more application characteristics. At 914, the gNB 210 may then activate or establish the I-SDT service or support for the application, e.g., including allocating resources, updating broadcast IoT-SIB to include the application specific system information for this application (e.g., application identifier and radio resources allocated for I-SDT for this application), and establishing a communications tunnel (or connectivity or connection) from gNB 210 to application server 230. At 916 and 918, the gNB 210 may sends a registration confirmation via core network 810 back to the application server to confirm that the application has been registered.

[0066] According to an example embodiment, over time the number of IoT applications registered for I-SDT operation may increase. As a result, a mechanism to maintain or store (current or updated) IoT-SIB information may be provided. This can be implemented, e.g., in the form of an expiration timer, e.g., if a given IoT application entry is not used by any UE for a predetermined (or threshold) amount of time, then this entry is dropped from the IoT-SIB (and thus application specific system information for that application would no longer be broadcast within the IoT-SIB). This mechanism ensures that the size of the IoT-SIB matches the IoT application needs, for example, and maintains only current or updated IoT application specific system information.

[0067] When the UE’s IoT application is registered with the gNB, and the application ID appears in the IoT-SIB from the gNB, then the UE proceeds with the I- SDT access (Idle-small data transmission) according with the resources (RACH preamble and/or PUSCH resources, or other radio resources) indicated in the IoT-SIB for that specific application identifier (AppID). The I-SDT can be performed using either 2-step RACH or 4-step RACH, e.g., where actual the IoT payload is transmitted over the PUSCH transmission (MsgA for 2-step RACH and Msg3 for 4-step RACH). Also, I- SDT data may also be sent via msg3 on PUSCH (which is UP channel) but is encapsulated in an RRC message.

[0068] According to an example embodiment, the size of the data or payload for the I-SDT message or transmission may be used as a basis to select either 2-step RACH or 4-step RACH for I-SDT. Thus, the difference between using 2-step RACH or 4-step RACH may be the size of the payload supported in the PUSCH transmission. In the 2- step RACH the supported payloads, e.g., may be less than 100 bits, while for 4-step RACH the payloads can be up to 1000 bits, according to an illustrative example.

[0069] During the I-SDT procedure, the UEs only transmit the IoT application via the radio resources indicated for the application specific payload (via the resources indicated in the broadcast IoT-SIB) and may not necessarily provide any other means of information in this payload. In case the IoT application requires identification, the UEs might include into the payload an application level identifier of the UE. In other words, the UE does not transmit any RAN level identifiers, as it is the case in normal 2-step and 4-step RACH access, such as a C-RNTI (a UE identifier may be omitted). Rather, an application level identifier of the UE or UE IoT application may be provided within the IoT data (I-SDT transmission). This is made possible since the resources through which the UE makes its I-SDT are reserved for the IoT application.

[0070] A possible implementation also can consider that the resources which the UE makes its I-SDT are not reserved for a single IoT application. Rather, the I-SDT resources indicated in the broadcast IoT-SIB for the application are provided for transmission of small data for a group or plurality of applications. In such cases, the UE can be configured to append the AppID (application identifier) to the transmitted payload of the I-SD. In such case, the gNB, upon receipt of the I-SDT small data may determine the application (and thus the application server to which the data should be forwarded) based on the appended application identifier

[0071] FIG. 10 is a diagram illustrating Idle state data transmission (I-SDT) via 2- step random access procedure and a 4-step random access procedure according to an example embodiment. In FIG. 10, an example is shown of an IoT application that allows the UEs to perform their I-SDT transmission with either 2-step or 4-step RACH. Note that in the example of FIG. 10, the UEs may receive an acknowledgement that their payload has been received by the gNB, which does not imply that the payload has already been received by the application server. Some applications might not require acknowledgment while other may require an acknowledgement. In the latter case, any failures over the RAN can be recovered by the usual retransmission mechanisms in 2 -step and 4-step. While failures over the CN can be recovered using high layer recovery mechanisms. The application server acknowledgement can be conveyed via the application specific information available in the IoT-SIB for the corresponding application. This acknowledgement can be provided for or at a group of UEs level or to specific UEs. Where the latter is achieved by including some specific pointer to the affected UE. The establishment of the UP tunnel between the gNB and the application server can be done in different ways, for example: The tunnel may be established in connection with the initial application registration and then remains open during the validity of the application registration. The tunnel may be established when the first UE registration request is received for the I-SDT procedure and then closes after a period of inactivity, for example.

[0072] As shown in FIG. 10, at 1010, UE1 receives the broadcast IoT-SIB (e.g., application specific system information for one or more IoT applications or applications for which the gNB 210 provide I-SDT services or support). UE1 may determine that an application identifier for an application is not included within the IoT-SIB, and thus, the application needs to be registered with gNB 210. Operations 1012, 1014, and 1016 illustrate I-SDT (Idle state small data transmission) via a 2-step random access (RACH) procedure. Whereas, operations 1020, 1022, 1024 and 1026 illustrate I-SDT via a 4-step random access (RACH) procedure.

[0073] With respect to the 2-step RACH shown in FIG. 10, at 1012, UE1 sends msgA of the 2-step RACH procedure (which may include an application specific RACH preamble), and at 1014 (which may be sent at the same time or in parallel as message at 1012), UE1 sends the I-SDT data via PUSCH resources (I-SDT payload) to gNB 210 (e.g., via the PUSCH (uplink shared channel) resources allocated for this IoT application, or allocated for a group of IoT applications for which I-SDT has been supported by the gNB 210. If application specific resources are used to transmit the data/payload, then the gNB can identify the application for which the received data is associated. Otherwise, if data is sent via resources allocated to a group of applications (or otherwise does not indicate the application), then the UE1 may include an application identifier within or appended to the data payload. At 1016, the gNB 210 receives the data, identifies the application for which the data is associated. At 1018, gNB 210 forwards the received data to the associated application server 230.

[0074] With respect to the 4-step RACH shown in FIG. 10, at 1020, the UE2 sends a random access preamble via msgl . At 1022, gNB 210 may send a random access response via msg2. At 1024, UE2 may send the IoT data (I-SDT data or payload) to the gNB 210 via msg3. At 1026, the gNB 210 may send an acknowledgement to the UE2. gNB 210 may determine or identify the application for which the received data is associated with (e.g., based on application specific resource via which the data is received, or based on an application identifier that may be provided within or appended to the data/payload). At 1028, the gNB 210 may forward the received data to the application server 230 that is associated or provided for the application.

[0075] Example 1. FIG. 11 is a flow chart illustrating operation of a user equipment (UE) according to an example embodiment. Operation 1110 includes receiving, by a user equipment from a base station, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more radio resources allocated for Idle state transmission of data for the application. Operation 1120 includes transmitting data for the application, by the user equipment to the base station via at least one of the one or more radio resources while the user equipment is in Idle state, wherein the application for the data is indicated based on either an application-specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data.

[0076] Example 2. The method of example 1 , further comprising: providing radio or application security or encryption for data transmitted between the user equipment and the base station.

[0077] Example 3. The method of any of examples 1-2 wherein the application for the data is indicated to the base station based on an application-specific radio resource used by the user equipment to transmit the data to the base station.

[0078] Example 4. The method of any of examples 1 -3 wherein the application for the data is indicated to the base station based on an application identifier that is included within the transmitted data.

[0079] Example 5 The method of any of examples 1-4, wherein the user equipment omits providing to the base station a user equipment identifier with respect to the network.

[0080] Example 6. The method of any of examples 1 -5 wherein the application identifier comprises at least one of: a number, code or identifier that has been assigned to the application; or a name of the application.

[0081] Example 7. The method of any of examples 1-6, wherein the information indicating one or more radio resources allocated for Idle state transmission of data for the application comprises at least one of the following: information identifying one or more application-specific random access preambles assigned to the application; or information identifying application-specific radio resources assigned to the application for an uplink data transmission.

[0082] Example 8. The method of any of examples 1-7 wherein the information indicating one or more radio resources allocated for Idle state transmission of data for the application comprises at least one of the following: information identifying one or more random access preambles assigned to a plurality of applications for which Idle state transmission is supported including the application; and/or information identifying radio resources, for uplink transmission, assigned to a plurality of applications for which Idle state transmission is supported including the application.

[0083] Example 9. The method of any of examples 1 -8, wherein the application information further comprises one or more characteristics of the application, or of the one or more radio resources allocated for use by the user equipment in idle state to transmit data for the application, including one or more of: whether a 2-step or 4-step random access procedure should be used for the transmitting of data for the application; a maximum data size for which the radio resources may be used for Idle state uplink data transmission; whether there will be an Acknowledgement sent from the base station to the user equipment to acknowledge receipt of the transmitted data; or a modulation and coding scheme (MCS) for data transmission for the application.

[0084] Example 10. The method of any of examples 1-9 wherein the transmitted data includes the application identifier to identify the application for which the transmitted data is for, in a case where the radio resource used for data transmission is not uniquely associated with the application.

[0085] Example 11. The method of any of examples 1-10, wherein an Idle state of the user equipment includes one or more of the following conditions for the user equipment: there is no connection established between the user equipment and the base station while the user equipment is in Idle state; and/or there is no dedicated radio network identifier assigned by the base station to the user equipment while the user equipment is in idle state.

[0086] Example 12. The method of any of examples 1-11, further comprising performing the following prior to the receiving and transmitting: receiving, by a user equipment from the base station, information that includes application information for one or more applications for which Idle state transmission is supported; determining, by the user equipment, that an application identifier identifying the application has not been received by the user equipment from the base station as part of the broadcast system information; sending, by the user equipment to the base station, a registration request to request registration of the application by the base station.

[0087] Example 13. The method of example 12, wherein the registration request comprises the application identifier that identifies the application and information identifying one or more characteristics of the application, wherein the characteristics include one or more of: a size of data transmissions for the application; a maximum data size or a maximum data payload for the application; a frequency or periodicity data for the application; a description of the application; an address of an application server associated with the application; an IP (Internet Protocol) address of an application server associated with the application; or a tunnel identifier that identifies a communications tunnel between the base station and the application server associated with the application.

[0088] Example 14. The method of any of examples 1-13, wherein the radio resources comprise: application-specific radio resources that are non-user equipment- specific, wherein the application-specific radio resources are allocated for transmission of data for the application.

[0089] Example 15. An apparatus comprising means for performing the method of any of examples 1-14.

[0090] Example 16. A non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by at least one processor, are configured to cause a computing system to perform the method of any of examples 1 -14.

[0091] Example 17. An apparatus comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of any of examples 1-14.

[0092] Example 18. An apparatus comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: receive, by a user equipment from a base station, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more radio resources allocated for Idle state transmission of data for the application; and transmit data for the application, by the user equipment to the base station via at least one of the one or more radio resources while the user equipment is in Idle state, wherein the application for the data is indicated based on either an application-specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data.

[0093] Example 19. The apparatus of example 18, wherein the apparatus is further caused to: provide radio or application security or encryption for data transmitted between the user equipment and the base station.

[0094] Example 20. The apparatus of any of examples 18-19 wherein the application for the data is indicated to the base station based on an application-specific radio resource used by the user equipment to transmit the data to the base station.

[0095] Example 21. The apparatus of any of examples 18-20 wherein the application for the data is indicated to the base station based on an application identifier that is included within the transmitted data.

[0096] Example 22. The apparatus of any of examples 18-21, wherein the user equipment omits providing to the base station a user equipment identifier with respect to the network.

[0097] Example 23. The apparatus of any of examples 18-22 wherein the application identifier comprises at least one of: a number, code or identifier that has been assigned to the application; or a name of the application.

[0098] Example 24. The apparatus of any of examples 18-23, wherein the information indicating one or more radio resources allocated for Idle state transmission of data for the application comprises at least one of the following: information identifying one or more application-specific random access preambles assigned to the application; or information identifying application-specific radio resources assigned to the application for an uplink data transmission.

[0099] Example 25. The apparatus of any of examples 18-24 wherein the information indicating one or more radio resources allocated for Idle state transmission of data for the application comprises at least one of the following: information identifying one or more random access preambles assigned to a plurality of applications for which Idle state transmission is supported including the application; and/or information identifying radio resources, for uplink transmission, assigned to a plurality of applications for which Idle state transmission is supported including the application.

[00100] Example 26. The apparatus of any of examples 18-25, wherein the application information further comprises one or more characteristics of the application, or of the one or more radio resources allocated for use by the user equipment in idle state to transmit data for the application, including one or more of: whether a 2-step or 4-step random access procedure should be used for the transmitting of data for the application; a maximum data size for which the radio resources may be used for Idle state uplink data transmission; whether there will be an Acknowledgement sent from the base station to the user equipment to acknowledge receipt of the transmitted data; or a modulation and coding scheme (MCS) for data transmission for the application.

[00101] Example 27. The apparatus of any of examples 18-26 wherein the transmitted data includes the application identifier to identify the application for which the transmitted data is for, in a case where the radio resource used for data transmission is not uniquely associated with the application.

[00102] Example 28. The apparatus of any of examples 18-27, wherein an Idle state of the user equipment includes one or more of the following conditions for the user equipment: there is no connection established between the user equipment and the base station while the user equipment is in Idle state; and/or there is no dedicated radio network identifier assigned by the base station to the user equipment while the user equipment is in idle state. [00103] Example 29. The apparatus of any of examples 18-28, wherein the apparatus is further caused to perform the following prior to the receiving and transmitting: receive, by a user equipment from the base station, information that includes application information for one or more applications for which Idle state transmission is supported; determine, by the user equipment, that an application identifier identifying the application has not been received by the user equipment from the base station as part of the broadcast system information; send, by the user equipment to the base station, a registration request to request registration of the application by the base station.

[00104] Example 30. The apparatus of example 29, wherein the registration request comprises the application identifier that identifies the application and information identifying one or more characteristics of the application, wherein the characteristics include one or more of: a size of data transmissions for the application; a maximum data size or a maximum data payload for the application; a frequency or periodicity data for the application; a description of the application; an address of an application server associated with the application; an IP (Internet Protocol) address of an application server associated with the application; or a tunnel identifier that identifies a communications tunnel between the base station and the application server associated with the application.

[00105] Example 31. The apparatus of any of examples 18-30, wherein the radio resources comprise:

[00106] application-specific radio resources that are non-user equipment-specific, wherein the application-specific radio resources are allocated for transmission of data for the application.

[00107] Example 32. FIG. 12 is a flow chart illustrating operation of abase station according to an example embodiment. Operation 1210 includes transmitting, by a base station, information that includes at least application information for a first application, the application information for the first application including at least an application identifier that identifies the first application, and information indicating one or more radio resources allocated for use by one or more user equipments in Idle state to transmit data for the first application to the base station. Operation 1220 includes determining, by the base station, an application server associated with the first application. Operation 1230 includes receiving, by the base station from a first user equipment via at least one of the one or more radio resources while the first user equipment is in Idle state, data of the first application, wherein the first application is indicated by the received data based on either an application-specific radio resource via which the data is received or based on an application identifier that is included within the received data. And, operation 1240 includes forwarding the received data of the first application to the application server associated with the first application.

[00108] Example 33. The method of example 32, further comprising: receiving, by the base station from the application server associated with the first application or a user equipment, a registration request to request registration of the first application by the base station, wherein the registration request includes an application identifier that identifies the first application.

[00109] Example 34. The method of example 33, wherein the registration request includes an application identifier that identifies the first application and information identifying one or more characteristics of the first application.

[00110] Example 35. The method of example 34, wherein the characteristics include one or more of: a size of data transmissions for the first application; a maximum data size or a maximum data payload for the first application; a frequency or periodicity data for the first application; a description of the first application; an address of an application server associated with the first application; an IP (Internet Protocol) address of an application server associated with the first application; or a tunnel identifier that identifies a communications tunnel between the base station and the application server associated with the first application.

[00111] Example 36. The method of any of examples 32-35, wherein the determining, by a base station, an application server associated with the first application comprises: determining an application-specific communications tunnel , associated with the first application, between the base station and the application server associated with the first application; wherein the forwarding comprises forwarding, by the base station, the received data of the first application to the application server via the communications tunnel.

[00112] Example 37. The method of any of examples 32-36, further comprising: determining, by the base station, that the data is for the first application based on an application-specific radio resource, allocated for the first application, via which the base station receives the data.

[00113] Example 38. The method of any of examples 32-37, further comprising: determining, by the base station, that the data is for the first application based on an application identifier, indicating the first application, that is included within the received data.

[00114] Example 39. The method of any of examples 32-38 wherein the application identifier comprises at least one of: a number, code or identifier that has been assigned to the first application; or a name of the first application.

[00115] Example 40. The method of any of examples 32-39, wherein the information indicating one or more radio resources allocated for use by the user equipment in Idle state to transmit data for the application comprises at least one of the following: information identifying one or more application-specific random access preambles assigned to the first application; or information identifying application-specific radio resources assigned to the first application for an uplink data transmission.

[00116] Example 41. The method of any of examples 32-40 wherein the information indicating one or more radio resources allocated for use by the user equipment in Idle state to transmit data for the first application comprises at least one of the following: information identifying one or more random access preambles assigned to a plurality of applications for which Idle state transmission is supported including the first application; and/or information identifying radio resources, for uplink transmission, assigned to a plurality of applications for which Idle state transmission is supported including the first application.

[00117] Example 42. The method of any of examples 32-41 , wherein the application information for the first application further comprises one or more characteristics of the first application, including one or more of: whether a 2-step or 4- step random access procedure should be used for the transmitting of data for the application; a maximum data size for which the radio resources may be used for Idle state uplink data transmission; whether there will be an Acknowledgement sent from the base station to the user equipment to acknowledge receipt of the transmitted data; or a modulation and coding scheme (MCS) for data transmission for the first application.

[00118] Example 43. The method of any of examples 32-42, wherein the received data includes the application identifier to identify the first application for which the received data is for, in a case where the radio resource used for data transmission is not uniquely associated with the first application.

[00119] Example 44. The method of any of examples 32-43, wherein the radio resources comprise: application-specific radio resources that are non-user equipment- specific, wherein the application-specific radio resources are allocated for transmission of data for the application.

[00120] Example 45. An apparatus comprising means for performing the method of any of examples 32-44.

[00121] Example 46. Anon-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by at least one processor, are configured to cause a computing system to perform the method of any of examples 32- 44.

[00122] Example 47. An apparatus comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of any of examples 32-44.

[00123] Example 48. An apparatus comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: transmit, by a base station, information that includes at least application information for a first application, the application information for the first application including at least an application identifier that identifies the first application, and information indicating one or more radio resources allocated for use by one or more user equipments in Idle state to transmit data for the first application to the base station; determine, by the base station, an application server associated with the first application; receive, by the base station from a first user equipment via at least one of the one or more radio resources while the first user equipment is in Idle state, data of the first application, wherein the first application is indicated by the received data based on either an application-specific radio resource via which the data is received or based on an application identifier that is included within the received data; and forward the received data of the first application to the application server associated with the first application.

[00124] Example 49. The apparatus of example 48, the apparatus further caused to: receive, by the base station from the application server associated with the first application or a user equipment, a registration request to request registration of the first application by the base station, wherein the registration request includes an application identifier that identifies the first application.

[00125] Example 50. The apparatus of example 49, wherein the registration request includes an application identifier that identifies the first application and information identifying one or more characteristics of the first application.

[00126] Example 51. The apparatus of example 50, wherein the characteristics include one or more of: a size of data transmissions for the first application; a maximum data size or a maximum data payload for the first application; a frequency or periodicity data for the first application; a description of the first application; an address of an application server associated with the first application; an IP (Internet Protocol) address of an application server associated with the first application; or a tunnel identifier that identifies a communications tunnel between the base station and the application server associated with the first application.

[00127] Example 52. The apparatus of any of examples 48-51 , wherein the apparatus being configured to determine an application server associated with the first application comprises the apparatus being caused to: determine an application-specific communications tunnel, associated with the first application, between the base station and the application server associated with the first application; wherein the apparatus being caused to forward comprises the apparatus being caused to forward, by the base station, the received data of the first application to the application server via the communications tunnel.

[00128] Example 53. The apparatus of any of examples 48-52, wherein the apparatus is further caused to: determine, by the base station, that the data is for the first application based on an application-specific radio resource, allocated for the first application, via which the base station receives the data.

[00129] Example 54. The apparatus of any of examples 48-53, wherein the apparatus is further caused to: determine, by the base station, that the data is for the first application based on an application identifier, indicating the first application, that is included within the received data.

[00130] Example 55. The apparatus of any of examples 48-54 wherein the application identifier comprises at least one of: a number, code or identifier that has been assigned to the first application; or a name of the first application.

[00131] Example 56. The apparatus of any of examples 48-55, wherein the information indicating one or more radio resources allocated for use by the user equipment in Idle state to transmit data for the application comprises at least one of the following: information identifying one or more application-specific random access preambles assigned to the first application; or information identifying application-specific radio resources assigned to the first application for an uplink data transmission.

[00132] Example 57. The apparatus of any of examples 48-56 wherein the information indicating one or more radio resources allocated for use by the user equipment in Idle state to transmit data for the first application comprises at least one of the following: information identifying one or more random access preambles assigned to a plurality of applications for which Idle state transmission is supported including the first application; and/or information identifying radio resources, for uplink transmission, assigned to a plurality of applications for which Idle state transmission is supported including the first application.

[00133] Example 58. The apparatus of any of examples 48-57, wherein the application information for the first application further comprises one or more characteristics of the first application, including one or more of: whether a 2-step or 4- step random access procedure should be used for the transmitting of data for the application; a maximum data size for which the radio resources may be used for Idle state uplink data transmission; whether there will be an Acknowledgement sent from the base station to the user equipment to acknowledge receipt of the transmitted data; or a modulation and coding scheme (MCS) for data transmission for the first application.

[00134] Example 59. The apparatus of any of examples 48-58, wherein the received data includes the application identifier to identify the first application for which the received data is for, in a case where the radio resource used for data transmission is not uniquely associated with the first application.

[00135] Example 60. The apparatus of any of examples 48-59, wherein the radio resources comprise: application-specific radio resources that are non-user equipment- specific, wherein the application-specific radio resources are allocated for transmission of data for the application.

[00136] Example 61. According to another example embodiment, a method may include receiving, by a user equipment from a base station, application information for at least one application, the application information including at least an application identifier that identifies the application, and information indicating one or more radio resources allocated for use by the user equipment for Idle state transmission of data for the application; and transmitting data for the application, by the user equipment to the base station via at least one of the one or more radio resources, wherein the application for the data is indicated based on either an application-specific radio resource used to transmit the data or based on an application identifier that is included within the transmitted data.

[00137] Example 62. The method of example 61 wherein the user equipment comprises at least one of: a user equipment in Idle state; or a user equipment in either Inactive state or connected State that behaves or operates as an Idle state user equipment with respect to the base station for a period of time by the user equipment not transmitting its dedicated radio network identifier assigned by the base station to the user equipment or other context information provided to the user equipment that is in Inactive state or Connected state.

[00138] Example 63. An apparatus comprising means for performing the method of any of examples 61-62.

[00139] Example 64. Anon-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by at least one processor, are configured to cause a computing system to perform the method of any of examples 61- 62.

[00140] Example 65. An apparatus comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of any of examples 61-62.

[00141] FIG. 13 is a block diagram of a wireless station (e.g., AP, BS or user device/UE, or other network node) 1300 according to an example embodiment. The wireless station 1300 may include, for example, one or more (e.g., two as shown in FIG. 13) RF (radio frequency) or wireless transceivers 1302 A, 1302B, where each wireless transceiver includes a transmitter to transmit signals and a receiver to receive signals.

The wireless station also includes a processor or control unit/entity (controller) 1304 to execute instructions or software and control transmission and receptions of signals, and a memory 1306 to store data and/or instructions.

[00142] Processor 1304 may also make decisions or determinations, generate frames, packets or messages for transmission, decode received frames or messages for further processing, and other tasks or functions described herein. Processor 1304, which may be a baseband processor, for example, may generate messages, packets, frames or other signals for transmission via wireless transceiver 1302 (1302A or 1302B). Processor 1304 may control transmission of signals or messages over a wireless network, and may control the reception of signals or messages, etc., via a wireless network (e.g., after being down-converted by wireless transceiver 1302, for example). Processor 1304 may be programmable and capable of executing software or other instructions stored in memory or on other computer media to perform the various tasks and functions described above, such as one or more of the tasks or methods described above. Processor 1304 may be (or may include), for example, hardware, programmable logic, a programmable processor that executes software or firmware, and/or any combination of these. Using other terminology, processor 1304 and transceiver 1302 together may be considered as a wireless transmiter/receiver system, for example.

[00143] In addition, referring to FIG. 13, a controller (or processor) 1308 may execute software and instructions, and may provide overall control for the station 1300, and may provide control for other systems not shown in FIG. 13, such as controlling input/output devices (e.g., display, keypad), and/or may execute software for one or more applications that may be provided on wireless station 1300, such as, for example, an email program, audio/video applications, a word processor, a Voice over IP application, or other application or software.

[00144] In addition, a storage medium may be provided that includes stored instructions, which when executed by a controller or processor may result in the processor 1304, or other controller or processor, performing one or more of the functions or tasks described above.

[00145] According to another example embodiment, RF or wireless transceiver(s) 1302A/1302B may receive signals or data and/or transmit or send signals or data. Processor 1304 (and possibly transceivers 1302 A/1302B) may control the RF or wireless transceiver 1302A or 1302B to receive, send, broadcast or transmit signals or data.

[00146] The embodiments are not, however, restricted to the system that is given as an example, but a person skilled in the art may apply the solution to other communication systems. Another example of a suitable communications system is the 5G system. It is assumed that network architecture in 5G will be quite similar to that of the LTE-advanced. 5G is likely to use multiple input - multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates.

[00147] It should be appreciated that future networks will most probably utilise network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into “building blocks” or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications this may mean node operations may be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labour between core network operations and base station operations may differ from that of the LTE or even be non-existent.

[00148] Embodiments of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Embodiments may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. Embodiments may also be provided on a computer readable medium or computer readable storage medium, which may be a non-transitory medium. Embodiments of the various techniques may also include embodiments provided via transitory signals or media, and/or programs and/or software embodiments that are downloadable via the Internet or other network(s), either wired networks and/or wireless networks. In addition, embodiments may be provided via machine type communications (MTC), and also via an Internet of Things (IOT). [00149] The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers include a record medium, computer memory, read only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers.

[00150] Furthermore, embodiments of the various techniques described herein may use a cyber-physical system (CPS) (a system of collaborating computational elements controlling physical entities). CPS may enable the embodiment and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers,...) embedded in physical objects at different locations. Mobile cyber physical systems, in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronics transported by humans or animals. The rise in popularity of smartphones has increased interest in the area of mobile cyber-physical systems. Therefore, various embodiments of techniques described herein may be provided via one or more of these technologies.

[00151 ] A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit or part of it suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[00152] Method steps may be performed by one or more programmable processors executing a computer program or computer program portions to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[00153] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer, chip or chipset. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data.

Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[00154] To provide for interaction with a user, embodiments may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a user interface, such as a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

[00155] Embodiments may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an embodiment, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

[00156] While certain features of the described embodiments have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the various embodiments.