DESC:FIELD OF INVENTION
[0001] The embodiments of the present disclosure generally relate to approaches for optimizing Quality of Service (QoS) in an Internet of Things (IoT) network. More particularly, the present disclosure relates to approaches for allocating network resources based on a Quality of Service (QoS) profile of a User Equipment (UE) in an Internet of Things (IoT) network.

BACKGROUND OF THE INVENTION
[0002] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0003] Generally, a plurality of devices such as sensors, user devices, and servers may be connected to form an Internet of Things (IoT) network. Currently, data from an IoT device may be treated as any other regular device and data is treated as any internet data and thus default Quality of Service (QoS) profile is set. Currently, there may be no such intelligence / mechanism that exists in the current ecosystem wherein the IoT applications / data is treated basis its overall end use case attributes in terms of reliability, latency sensitivity. In real world, there exists many such IoT applications wherein the data can be sent across the system post certain delay in which cases the network can cache the data and send it over a period of time owing to its resource and computation load. Also, certain data might need certain computation owing to end use case scenario.
[0004] For instance, in an agriculture IoT environment, the data collected by various sensor may not be time critical and thus there may be no need to send across the system instantaneously and can be cached at various levels and sent across may be once a day or as configured by an application server or the device in the system based on the end use case scenario. Also, the sensor data collected such as soil – PH, moisture, etc won’t be sent as-is, as it may not make any sense to the end user and needs certain computation or mathematical statistical models to be executed to make a meaningful data out of it. Such computation may be done at various levels – device, RAN or the application server or at application Function (part of 5G network). So, in essence - IOT applications may be latency insensitive or latency sensitive. Latency insensitive application data may be cached in the Radio Access System (RAS) for extended periods of time before the data is sent to an application server.
[0005] Conventional methods to identify if an application is latency sensitive or latency insensitive and further if such an application may need caching and/or data processing support at the Enhanced Data rates for GSM Evolution (EDGE) or at the radio access entities does not exist. The existing cellular network (Fourth generation (4G), 5G, NB-IoT) support QoS categories that are not appropriate for the emerging IoT application types. The IoT application types may range from latency sensitive categories such as medical IoT devices to latency insensitive devices or application types such as soil sensor IoT devices used in agricultural fields. Conventional QoS parameters may involve values such as “throughput, transit delay, priority, protection”, however the conventional QoS parameters may not involve, if a data stream, packet of data or any data originating from a device needs caching, the locality of caching, if data needs local processing the nature of processing details.
[0006] There is therefore a need in the art to provide a methods and systems that can overcome the shortcomings of the existing prior art.

OBJECTS OF THE PRESENT DISCLOSURE
[0007] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.
[0008] An object of the present disclosure is to provide systems and methods for efficient, latency sensitivity, and reliable optimizing of Quality of Service (QoS) in an Internet of Things (IoT) network.
[0009] Another object of the present disclosure is to provide systems and methods for new QoS profiles that will help identify if an application is latency insensitive, needs caching support and /or federated processing capabilities at the EDGE and or the radio access nodes.
[0010] Another object of the present disclosure is to provide systems and methods to support additional compute entities in the radio access network that may perform intelligent data processing for the specific applications.
[0011] Another object of the present disclosure is to provide systems and methods that is aware of the IOT application category or type which will then be used by the IOT network to appropriately assign new QoS classes appropriately.
[0012] Another object of the present disclosure is to provide systems and methods for signalling to change priorities between the category types as some application priorities are relative (Ex: from latency insensitive to latency sensitive types).
[0013] Another object of the present disclosure is to provide systems and methods which utilizes modem interface between the applications to the Non-Access stratum (NAS) that can map the new application categories to the defined new QoS class identifiers.
[0014] Another object of the present disclosure is to provide systems and methods for treating IoT applications / data based its overall end use case attributes in terms of reliability, latency sensitivity.
[0015] Another object of the present disclosure is to provide systems and methods to involve Qos parameters such as, data stream, packet of data or any data originating from a device needs caching, the locality of caching, if it needs local processing the nature of processing details.
[0016] Another object of the present disclosure is to provide systems and methods for a QoS mechanism of extended QoS template, the mechanism of interpreting and applying such a new QoS template for latency insensitive applications.

SUMMARY
[0017] Embodiments of the present disclosure of the objects of the present disclosure relate to approaches for optimizing Quality of Service (QoS) in an Internet of Things (IoT) network. More particularly, the present disclosure relates to approaches for allocating network resources based on a Quality of Service (QoS) profile of a User Equipment (UE) in an Internet of Things (IoT) network.
[0018] An embodiment of the present disclosure pertains to a system for allocating network resources based on a Quality of Service (QoS) profile of a User Equipment (UE) in an Internet of Things (IoT) network. The system may include a processor, and an analysis engine coupled to the processor. The analysis engine may be configured to receive a request from a User Equipment (UE). The UE may be in communication with the system over a network. Further, the received request may include a set of UE parameters. Thereafter, the set of UE parameters may be extracted from the received request. Based on the extracted set of UE parameters, a Quality of Service (QoS) profile may be assigned to the request. Thereafter, based on the assigned QoS profile, at least one of a plurality of network resources may be allocated to the UE generating the request.
[0019] In one aspect, the request may be received from the UE through a communications modem. The communications modem may be communicatively coupled to the UE and the system, over the network.
[0020] In another aspect, the analysis engine may be further configured to establish a Protocol Data Unit (PDU) session with the UE based on the received request from the UE.
[0021] In yet another aspect, the analysis engine may assign the QoS profile to the profile based on a pre-defined mapping criteria.
[0022] In yet another aspect, the analysis engine may categorise the request from the UE, based on the extracted set of UE parameters, to be one of a latency sensitive request and a latency insensitive request.
[0023] In yet another aspect, the allocation of the plurality of network resources to the UE generating the request may include one of an allocation of processing resources, allocation of memory resources, assigning priority level of execution, or a combination thereof.
[0024] In yet another aspect, allocating the processing resources to the UE may include causing the UE generating the request to utilize one of a plurality of processing resources of one of a plurality of entities in the network.
[0025] In yet another aspect, allocating the memory resources to the UE may include causing the UE generating the request to utilize one of a plurality of cache memories of one of a plurality of entities in the network.
[0026] In yet another aspect, assigning priority level of execution to the UE may include causing a delay in executing the request for a certain period of time.
[0027] In yet another aspect, the set of UE parameters may include one of a sensor data, an application data, or a combination thereof.
[0028] In yet another aspect, the sensor data may be obtained from one of a plurality of sensors in communication with the UE.
[0029] In yet another aspect, the application data may be obtained from an application executing on the UE.
[0030] Another embodiment of the present disclosure pertains to a method for allocating network resources based on a Quality of Service (QoS) profile of a User Equipment (UE) in an Internet of Things (IoT) network. The method may include the steps of: receiving, by an analysis engine, a request from a User Equipment (UE). The UE may be in communication with the system over a network. Further, the received request may include a set of UE parameters. Thereafter, the set of UE parameters may be extracted from the received request. Based on the extracted set of UE parameters, a Quality of Service (QoS) profile may be assigned to the request. Thereafter, based on the assigned QoS profile, at least one of a plurality of network resources may be allocated to the UE generating the request.
[0031] In one aspect, the request may be received from the UE through a communications modem. The communications modem may be communicatively coupled to the UE and the system, over the network.
[0032] In another aspect, the method may further include establishing a Protocol Data Unit (PDU) session with the UE based on the received request from the UE.
[0033] In yet another aspect, assigning the QoS profile to the profile may be based on a pre-defined mapping criteria.
[0034] In yet another aspect, the method may further include categorising the request from the UE, based on the extracted set of UE parameters, to be one of a latency sensitive request and a latency insensitive request.
[0035] In yet another aspect, allocating the plurality of network resources to the UE generating the request may include allocating processing resources, allocating memory resources, assigning priority level of execution, or a combination thereof.
[0036] In yet another aspect, allocating the processing resources to the UE may include causing the UE generating the request to utilize one of a plurality of processing resources of one of a plurality of entities in the network.
[0037] In yet another aspect, allocating the memory resources to the UE may include causing the UE generating the request to utilize one of a plurality of cache memories of one of a plurality of entities in the network.
[0038] In yet another aspect, assigning priority level of execution to the UE may include causing a delay in executing the request for a certain period of time.
[0039] In yet another aspect, the set of UE parameters may include one of a sensor data, an application data, or a combination thereof.
[0040] In yet another aspect, the sensor data may be obtained from one of a plurality of sensors in communication with the UE.
[0041] In yet another aspect, the application data may be obtained from an application executing on the UE.
[0042] Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF DRAWINGS
[0043] The accompanying drawings, which are incorporated herein, and constitute a part of this invention, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that invention of such drawings includes the invention of electrical components, electronic components or circuitry commonly used to implement such components.
[0044] FIG. 1 illustrates an exemplary network architecture in which or with which proposed system of the present disclosure can be implemented, in accordance with an embodiment of the present disclosure;
[0045] FIG. 2 illustrates an exemplary representation of proposed system for optimizing Quality of Service (QoS) in an Internet of Things (IoT) network, in accordance with an embodiment of the present disclosure;
[0046] FIG. 3 illustrates a flowchart for optimizing Quality of Service (QoS) in an Internet of Things (IoT) network, to be implemented in the system, in accordance with an embodiment of the present disclosure;
[0047] FIG. 4 illustrates an exemplary sequence diagram representation of computation levels for QoS setting, in accordance with an embodiment of the present disclosure;
[0048] FIGS. 5A-5E illustrate exemplary sequence diagram representations of Application Type (AT) commands between the Application and the communication modem, in accordance with an embodiment of the present disclosure;
[0049] FIG. 5F illustrates an exemplary block diagram representation of caching level in a general network architecture, in accordance with an embodiment of the present disclosure;
[0050] FIG. 5G illustrates an exemplary flow diagram representation of method for automatic detection of application type across the system, in accordance with an embodiment of the present disclosure;
[0051] FIG. 5H illustrates an exemplary sequence diagram representation of Application Server (AS) configuring the communication network and as well the modem on the QoS profile based on the awareness of the application type, in accordance with an embodiment of the present disclosure;
[0052] FIG. 5I illustrates an exemplary sequence diagram representation of Application Type (AT) commands in Fifth Generation (5G) network architecture, in accordance with an embodiment of the present disclosure;
[0053] FIG. 5J illustrates an exemplary sequence diagram representation of Application Type (AT) commands using a new Non-access stratum (NAS) in Fifth Generation (5G) network architecture, in accordance with an embodiment of the present disclosure;
[0054] FIG. 5K illustrates an exemplary sequence diagram representation of Application Type (AT) commands using a new Non-access stratum (NAS) during lost User Equipment context/application type lost scenario during/ post-handover, in Fifth Generation (5G) network architecture, in accordance with an embodiment of the present disclosure; and
[0055] FIG. 6 illustrates an exemplary computer system in which or with which embodiments of the present invention can be utilized, in accordance with embodiments of the present disclosure.
[0056] The foregoing shall be more apparent from the following more detailed description of the invention.

DETAILED DESCRIPTION OF INVENTION
[0057] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0058] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth.
[0059] The present disclosure provides approaches for optimizing Quality of Service (Qos) in an Internet of Things (IoT) network. As per the approaches of the present subject matter, network resources may be allocated to various User Equipments (UEs) in the network based on their respective QoS profiles. Various applications executing on different UEs may be analysed, and based on their latency sensitivity level, network resources may be accordingly assigned to them. In one example, caching support and federal processing capabilities may be provided. In another example, the application and the corresponding UE may be assigned a certain processing resource in the network to improve the overall QoS of the network. As would be appreciated, the present subject matter may thus provide for efficient, latency sensitivity, and reliable optimizing of Quality of Service (QoS) in an Internet of Things (IoT) network.
[0060] In another example, the present disclosure provides systems and methods to support additional compute entities in the radio access network that may perform intelligent data processing for the specific applications. In yet another example, the present disclosure provides systems and methods that is aware of the IOT application category or type which will then be used by the IOT network to appropriately assign new QoS classes appropriately. In yet another example, the present disclosure provides systems and methods for signalling to change priorities between the category types as some application priorities are relative (e.g., from latency insensitive to latency sensitive types). In yet another example, the present disclosure provides systems and methods which utilizes modem interface between the applications to the Non-Access stratum (NAS) that can map the new application categories to the defined new QoS class identifiers. In yet another example, the present disclosure provides systems and methods for treating IoT applications / data based its overall end use case attributes in terms of reliability, latency sensitivity. In yet another example, the present disclosure provides systems and methods to involve QoS parameters such as, data stream, packet of data or any data originating from a device needs caching, the locality of caching, if it needs local processing the nature of processing details. In yet another example, the present disclosure provides systems and methods for a QoS mechanism of extended QoS template, the mechanism of interpreting and applying such a new QoS template for latency insensitive applications.
[0061] This and other aspects will be described in further details in conjunction with FIGS. 1-6. It may be noted that the figures are only illustrative, and should not be construed to limit the scope of the present subject matter in any manner. It may be further noted that FIGS. 1-3 have been explained in conjunction, and same reference numerals have been used wherever applicable.
[0062] Referring to FIG. 1 that illustrates an exemplary network architecture 100 for a Quality of Service (QoS) optimizing system (also referred to as network architecture 100), in accordance with an embodiment of the present disclosure. As depicted in FIG. 1, a plurality of user equipments (UEs) 102-1, 102-2, 102-3, …, 102-N (collectively referred to as User Equipment (UE) 102) may be in communication with an application server 104 over a network 106.
[0063] In one example, the UE 102 may include, but not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as mobile phone, smartphone, Virtual Reality (VR) devices, Augmented Reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, an IoT sensor, an IoT device, IoT appliances, mainframe computer, or any other computing device, wherein the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen, receiving devices for receiving any audio or visual signal in any range of frequencies and transmitting devices that can transmit any audio or visual signal in any range of frequencies. It may be appreciated that the UE 102 may not be restricted to the mentioned devices and various other devices may be used. A smart computing device may be one of the appropriate systems for storing data and other private/sensitive information.
[0064] Further, the application server 104 may be implemented as any hardware-based, software-based, network-based, or cloud-based server. The In another example, the application server 104 may be an Application Server (AS) or an IoT server.
[0065] In another example, the application server 104 may be in communication with a plurality of other components in the network 100 such as AMF (Access and Mobility Management function), SMF (Session Management Function), PCF (Policy Control Function), UPF (User Plane Function), DN (Data Network), etc. These components have been depicted in FIG. 4, and explained in the description later. In yet another example, such components may be a part of the application server 104. Any other implementation would also be covered within the scope of the present subject matter.
[0066] In yet another example, the application server 104 may be a System On Chip (SoC) system but not limited to the like. In yet another example, an onsite data capture, storage, matching, processing, decision-making and actuation logic may be coded using Micro-Services Architecture (MSA) but not limited to it. A plurality of microservices may be containerized and may be event based in order to support portability.
[0067] In yet another example, the network architecture 100 may be modular and flexible to accommodate any kind of changes in the application server 104 as proximate processing may be acquired towards optimizing Quality of Service (QoS) in an Internet of Things (IoT) network. The application server 104 configuration details can be modified on the fly.
[0068] In yet another example, the application server 104 may be remotely monitored and the data, application and physical security of the application server 104 may be fully ensured. In an embodiment, the data may get collected and deposited in a cloud-based data lake to be processed to extract actionable insights. Therefore, the aspect of predictive maintenance can be accomplished. In another exemplary embodiment, the application server 104 may include or comprise, by way of example but not limitation, one or more of: a stand-alone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof.
[0069] The application server 104 may include an analysis engine (not shown in FIG. 1). In one example, the analysis engine may be a part of the application server 104. In another example, the analysis engine may be in communication with the application server 104. In yet another example, the analysis engine may be implemented over a centralized server, and such centralized server may be in communication with the application server 104. Any other implementations of the analysis engine may also be covered within the scope of the present subject matter.
[0070] The UE 102 may be further in communication with a plurality of sensors (not shown in FIG. 1). Such sensors may be in communication with the respective UE 102 and may continuously monitor a condition. These sensors, UE 102, and application server 102 may be in communication with each other and may form a part of the IoT network.
[0071] The network 106 may be implemented as a IoT communication network. The network 106 can be a wireless network, a wired network or a combination thereof that can be implemented as one of the different types of networks, such as Intranet, Local Area Network (LAN), Wide Area Network (WAN), Internet, and the like. Further, the network 106 can either be a dedicated network or a shared network. The shared network can represent an association of different types of networks that can use variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like.
[0072] In an exemplary embodiment, the IoT communication network 106 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. A network may include, by way of example but not limitation, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, some combination thereof.
[0073] In one example, the UE 102 may communicate with the application server 104 via set of executable instructions residing on any operating system, including but not limited to, AndroidTM, iOSTM, Kai OSTM, and the like.
[0074] The working of the application server 104 for allocating network resources based on a QoS profile of the respective UE 102, and thus optimizing the QoS of the network environment 100 is explained in further details in conjunction with FIG. 2 and FIG. 3.
[0075] FIG. 2 illustrates an exemplary representation of proposed system for optimizing Quality of Service (QoS) in an Internet of Things (IoT) network, in accordance with an embodiment of the present disclosure. In one example, the system may be implemented as the application server 104 as explained in FIG. 1.
[0076] As depicted in FIG. 2, the application server 104 may include one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the application server 104. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may comprise any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.
[0077] In an embodiment, the application server 104 may include an interface(s) 106. The interface(s) 106 may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, and the like. The interface(s) 106 may facilitate communication of the application server 104. The interface(s) 106 may also provide a communication pathway for one or more components of the application server 104. Examples of such components include, but are not limited to, processing engine(s) 208 and a database 210.
[0078] The processing unit/engine(s) 208 may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) 208. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) 208 may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) 208 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) 208. In such examples, the application server 104 may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the application server 104 and the processing resource. In other examples, the processing engine(s) 208 may be implemented by electronic circuitry.
[0079] The processing engine 208 may include an analysis engine 212, and other engines 214. In one example, the processing engine 208 may be based on an edge-based micro service event processing but not limited to the like.
[0080] It may be noted that, although the present description will be described in context of a single UE 102, the same is done only for the purpose of clarity. The approaches of the present subject matter may be implemented in a network of a plurality of UEs 102 in the network environment 100 without deviating from the scope of the present subject matter.
[0081] In operation, an application 108 may be executing on the UE 102. In one example, the application 108 may be an application type which runs the software logic as per the end user requirement. The application 108 while executing, may be required to utilize some resources from the network 100. Examples of such network resources may include, but are not limited to, processing resources and memory resources. Such application 108, during execution, may be in communication with the sensors of the UE 102. The application 108, executing on the respective UE 102, may cause the corresponding UE 102 to generate a request. In an embodiment, the request may then be received by the application server 104 (depicted as block 302 in FIG. 3). Such a request may be used by UE 102 to communicate with the application server 104 to utilize some of the available network resources.
[0082] In another example, the request may be communicated from the UE 102 to the application server 104 through a communications modem 110. The communications modem 110 may be implemented as any hardware-based or software-based computing device. In another example, the communications modem 110 may be a part of the UE 102. In yet another example, the communication modem (206) may be a modem based on Second Generation (2G) / Third Generation (3G) / Long Term Evolution (LTE) / Narrow Band Internet of Things (NB-IoT) / Fifth Generation (5G) / Sixth generation (6G) or any other communication networks over Local Area Network (LAN) / Wide Area Network (WAN). However, it may be noted that such examples are only illustrative, and the request may be communicated from the UE 102 to the application server 104 in any manner without deviating from the scope of the present subject matter.
[0083] Continuing further, upon receiving the request from the UE 102, the application server 104 may establish a Protocol Data Unit (PDU) session with the UE 102. The received request from the UE 102 may include a set of UE parameters. In one example, the set of UE parameters may be a metadata that is generated by the UE 102. In another example, the set of UE parameters may include one of a sensor data, an application data, or a combination thereof. In yet another example, the sensor data may be obtained from one of a plurality of sensors, which may be in communication with the corresponding UE 102. In yet another example, the application data may be obtained from the application 108 executing on the UE based on one or more factors. In yet another example, the metadata may include a pre-determined flag bits or some priority class identifier bits that may be set by the user of the UE 102 while executing the application. Such priority class identifier may be set on the fly by the application 108 itself or may be set as a constant at the time of downloading the application 108 to the UE 102. As would be understood, the UE parameter may be indicative of the manner in which the application 108 may be executing on the UE 102 and the network resources required by the execution of the said application 108.
[0084] Continuing further, the UE parameter may then be extracted from the received request (depicted as step 304 in FIG. 3). Thereafter, based on the extracted UE parameter, a Quality of Service (QoS) profile may be assigned to the corresponding request (depicted as step 306 in FIG. 3). In one example, the analysis engine 212 may assign the QoS profile to the corresponding request based on a pre-defined mapping criteria. In another example, the analysis engine 212 may categorise the corresponding request from the corresponding UE to be one of a latency sensitive request and a latency insensitive request.
[0085] In another example, upon categorizing a QoS profile of the received request from a corresponding UE as latency sensitive or latency insensitive, the analysis engine 212 may further classify the QoS profile into multiple categories based on the grade of latency insensitivity of the said applications.
[0086] Continuing further, based on the assigned QoS profile, at least one of a plurality of network resources may then be allocated to the corresponding UE generating the corresponding request (depicted as step 308 in FIG. 3). In one example, the plurality of network resources allocated to the corresponding UE generating the corresponding request may include one of an allocation of processing resources, allocation of memory resources, assigning priority level of execution, or a combination thereof. In another example, the analysis engine 212 may cause the corresponding UE generating the corresponding request to utilize one of a plurality of processing resources of one of a plurality of entities in the network. In yet another example, the analysis engine 212 may cause the corresponding UE generating the corresponding request to utilize one of a plurality of cache memories of one of a plurality of entities in the network. In yet another example, the analysis engine 212 may cause a delay in executing the corresponding request for a certain period of time.
[0087] In yet another example, the analysis engine 212 may allocate a caching mechanism based on the allocated memory resources. In yet another example, upon determining the QoS profile and allocating the network resources, the analysis engine 212 may cause the application 108 to use an Application Type (AT) commands to make the communication modem 110 and the network 106 aware of the application type to configure and map the new identified QoS profile. The AT command interfaces may identify the application type, sensor type and the necessary signalling identifiers to let the network know of the right type of QoS profile to identify and apply.
[0088] In yet another example, the analysis engine 212 may cause the architectural entities in the IoT communication network 106 to read and interpret the QoS profile to execute the necessary attributes of the QoS profile including possible caching and execution of appropriate compute algorithms. Such additional compute entities in the IoT radio access network such as the IoT communication network 106 may perform intelligent data processing for the specific applications.
[0089] In yet another example, the different levels of caching and computational entities may be defined for latency insensitive application type for carrying out intelligent data processing and configuration as appropriate via appropriate Radio Access Network (RAN) signalling mechanisms.
[0090] In yet another example, system and flow of the network architecture 100 may be defined to change the priority dynamically between latency sensitive vs insensitive based on any of the following methods such as application triggers based on AT commands, network identifying a change of priority intelligently, and the application server 104 identifying and appropriately signalling either the UE 102 or the IoT RAN entity (not shown in FIGS. 1-2).
[0091] In yet another example, the application priority change type may be detected by the IoT communication network 106 intelligently and in turn to configure the QoS profile. In yet another example, the analysis engine 212 may cause the Application Server 104 to configure the new QoS profile in the IoT communication network 106 as well as in the communication modem 110 based on the awareness of the application type.
[0092] In yet another example, for a sensor based IoT device such as the UE 102 in which traffic characterization is such that at a pre-defined period a set of bytes of traffic data is sent and post which nothing will be sent until the next timer expires. In such cases, the IoT communication network 106 may decide not to have RRC inactive state defined and may release the resources and reuse the same for other needed devices.
[0093] In order to accommodate the above application types, new QoS profiles may be implemented that may help to identify if an application is latency insensitive, needs caching support and /or federated processing capabilities at the Enhanced Data rates for GSM Evolution (EDGE) and or the radio access nodes. The network architecture 100 may support additional compute entities in the RAN that may perform intelligent data processing for the specific applications.
[0094] In an example, the network architecture 100 may be aware of the IoT application category or type which may then be used by the IoT communication network 106 to appropriately assign new QoS classes appropriately. This may be necessary to optimize resources in a network, new QoS categories may handle such application types. Further, the signalling may change priorities between the category types as some application priorities are relative (e.g., from latency insensitive to latency sensitive types). Specifically, a new modem interface between the application 108 to the Non-Access stratum (NAS) may map the new application categories to the defined new QoS class identifiers. Such IoT application categories may also support further subcategories.
[0095] In another example, a QoS mechanism of extended QoS template may be provided, the mechanism may be used for interpreting and applying a new QoS template for latency insensitive applications. In an embodiment, the server 104 may define a QoS template or profile that helps define the attributes of the application.
[0096] In yet another example, Latency insensitive applications can be claissfied to four different sub categories to cater for different use case scenarios such as:
Grade 1 – Delay tolerant up to 24 hours or more.
Grade 2 – Delay tolerant in few hours but less than 24 hours.
Grade 3 – Delay tolerant in terms of 10’s of minute.
Grade 4 – Delay tolerant in terms of minutes but less than 10 minutes.
[0097] In yet another example, allocating the network resources may further include determining a need for caching, locality of caching, requirement for processing, nature of processing, processing indicators, concatenation of packets, averaging of data, thresholding of incoming data, and application of a specified data aggregation mechanism. However, it may be noted that such examples are only illustrative, and should not be construed to limit the scope of the present subject matter in any manner. Any other network resources allocation technique would also be covered within the scope of the present subject matter.
[0098] These and other exemplary aspects and embodiments have been explained in FIGS. 4-5.
[0099] FIG. 4 illustrates an exemplary sequence diagram representation of computation levels for QoS setting, in accordance with an embodiment of the present disclosure.
[00100] Registration -> PDU establishment (latency insensitive type) - > SMF (406) to indicate RAN (402) (CU-UP) or UPF (410) to cache and caching related parameters such as storage space, data processing / packaging, storage classes based on UPF (410), related timers, and so on.
[00101] At step (414-1), the application (108) may application type (latency sensitive) is transmitted to modem (110). At step (414-2) the modem (110) may transmit PDU establishment request to the RAN (402). At step (414-3), the modem (110) may transmit Radio Resource Control (RRC) connection request to the RAN (402). At step (414-4), the RAN (402) may transmit back RRC connection acknowledgment to the modem (110). At step (414-5), the AMF (404) may perform SMF selection. At step (414-6), the AMF (404) may transmit Nsmf (i.e., Service-based interface exhibited by SMF) PDU session to create SM context request to the SMF (416).
[00102] At step (414-7), the SMF (406) may transmit back Nsmf PDU session to create SM response to the AMF (404). At step (414-8) the AMF (404) may transmit set context request to the SMF (406). At step (414-9), the SMF (406) may transmit conformation on set context to the AMF (404).
[00103] At step (414-10) the SMF (406) may select Policy Control Function (PCF) at step (414-11), the SMF (406) may modify SM initiated policy association including establishment cause, at step (414-12) the SMF (406) may select UPF. At step (414-13), the SMF (406) may transfer N1 N2 message to the AMF (404). At step (414-14), the SMF (406) may transmit PFCP message with additional parameter IE for caching to the UPF (410). At step (414-15) the AMF (404) may transmit PDU session request with new QFI to the RAN (402). At step (414-16), the RAN (402) may transmit PDU establishment acknowledgement to the modem (110).
[00104] FIGS. 5A-5E illustrate exemplary sequence diagram representations of Application Type (AT) commands between the Application and the communication modem. The application may be implemented as the 108 and the communication modem may be implemented as communications modem 110 as described in FIG. 1. In sequence diagram of FIG. 5A, the UE (102) and the modem (110) may perform steps (502-1) to (502-11). In sequence diagram of FIG. 5B, the UE (102) and the modem (110) may perform steps (504-1) to (504-14). In sequence diagram of FIG. 5C, the UE (102) and the modem (110) may perform steps (506-1) to (506-3). In sequence diagram of FIG. 5D, the UE (102) and the modem (110) may perform steps (508-1) to (508-4). In sequence diagram of FIG. 5E, the UE (102) and the modem (110) may perform steps (510-1) to (510-2).
[00105] It is to be noted that once the modem receives the sensor data, same shall be sent over the control channel or data channel and sensor capability, same shall be sent over the UE capability message, application type, the above data on application type when received from the application, modem may use the same to send to the network during PDU establishment / modification / registration procedure via Service Request Establishment_Cause IE as seen below:
EstablishmentCause ::= ENUMERATED {emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, mps-PriorityAccess, mcs-PriorityAccess, IoT-LatencySens / IoT-LatencyInsen, IoT-DataReliability, spare4, spare3, spare2, spare1}.
[00106] Once network receives the above Establishment_Cause, RAN shall forward the same to AMF and then to SMF and via SMF to PCF. PCF shall finally set the QCI / 5QI and other parameters accordingly using the existing mechanism. A similar flow applies for 4G or other technologies as well and not just limited to 5G NR. 5G NR is taken here for an example per say only.
[00107] FIG. 5F illustrates an exemplary block diagram representation of caching level in a general network architecture, in accordance with an embodiment of the present disclosure.
[00108] As described previously, based on the assigned QoS profile, at least one of a plurality of network resources may be allocated to the corresponding UE generating the corresponding request. In one example, based on the level of latency sensitivity, different caching levels may be defined. FIG. 5F depicts one of different possible ways to cache the content in latency insensitive use cases to save network resources and computational power. The caching level in the general network architecture may include the UE (102), an Access Network (512), a Core Network (514), and a Data Network (DN)/Internet (412).
[00109] As further depicted, C1-C6 (i.e., UE (102), Radio Access Network (RAN) (402), a User plane function (UPF) (410), a Data Network (DN) (412), an Access and Mobility Management function (AMF) (404), a Session Management function (SMF) (406), an Application Function (AF) (516), and a Policy Control Function (PCF) (408)) may be different possibilities location of caching that can be done for data acquired from the UE (102) or IoT device that has been confirmed or configured for latency insensitive use cases or services.
[00110] More preferred location of caching may be in the RAN (402) at Centralized Unit User Plane (CU-UP) and same shall be communicated via the SMF (406) (as a master to configure the same). A mechanism for the SMF (406) to communicate for UPF (410) or CU-UP to perform caching and computation shall be communicated as part of the flows defined below while setting the QoS profile during PDU establishment procedures. Once the QoS template is applied the SMF (406) entity as part of its signalling will have to provide additional information to the cache location along with the additional parameters as seen below. As part of the flow, parameters may be conveyed by the SMF (406) regarding the content caching (including data integrity) or to have default configuration set based on the 5QI values, such as:
Memory footprint- This helps UPF or CU-UP to allocate the memory for content caching per UE or class of devices
Time for which content to be cached- This is the timer to indicate for how long the content needs to be cached.
Apart from the content caching, following different level of caching shall be defined to see, messages – L0 - Meaning only regular data or messages to be cached, alerts / warnings – L1 – even alarms / warnings shall be cached, configuration – L2 – Configurations also shall be cached, and so on.
[00111] The new proposed schema or structure of the above may be as shown below:
CachingParametersIE::={
CachingLocation::=ENUM{C1, C2, C3, C4… },
CachingLevel::= ENUM{L0,L1,L2..},
Memroy::STRING{XKB, YMB…},
Timer::=STRING{xh:ym:zs},
MaxAttempts::= N}}
[00112] All the above described configuration may be passed to the caching entity by the SMF (406) post PCF configures the QoS profile. Apart from the timer indicating when the message to be flushed to the emergency server, it may also to be noted that the message can be transferred when the allotted memory gets filled before the timer expires or can be flushed once the number of attempts to transfer the content is reached its maximum limit. Further, max limit for the same shall be communicated as part of the above structure.
[00113] Computation Levels, similar to caching, computation levels may also be communication part of the QoS setting. Computation may happen at different entities like CU-UP, UPF or a totally a new entity that shall be introduced in the architecture wherein all the EDGE computation, or any algorithm or mathematical statistical models may be implemented. For an instance, sensor data that needs to be collected for an Agriculture-IoT scenario can be configured for EDGE computation or at the designated entity. For instance, there may be three different ways to communicate the application type across the system to configure the right QoS Profile in such an IoT system. In one example, this may be implemented using AT commands. In such cases, the application and modem may interact via AT interface to exchange the QoS profile. In another example, such implementation may be done using the application server. In such cases, the application server may configure the QOS profile. In yet another example, such implementation may be done automatically.
[00114] FIG. 5G illustrates an exemplary flow diagram representation of method (500) for automatic detection of application type across the system, in accordance with an embodiment of the present disclosure.
[00115] At block (518-1), when network initially sets a default QoS while establishing the PDU session, network at the RAN level keeps collecting the data analyses the traffic pattern. The method decides on sensitiveness of QoS profile latency. if yes, at block (518-3), the network sets 5QI as “Y” and communicates the same to all entities involved – PCF, AMF, SMF, RAN and UE. If not, at step (518-2), network sets 5QI as “X” and communicates the same to all entities involved – PCF, AMF, SMF, RAN and UE.
[00116] Either part of RIC (Radio Intelligent Controller) or part of CU-UP or DU-UP, data collection and traffic pattern analysis is expected to happen. Once the traffic pattern is analyzed, using the below flow as defined in section 3 (post AT command definition) will be used to share to AMF – SMF – PCF on the cause and thereby the right QCI is set. Initially the default QCI as per the existing procedure is used to define till above procedure refines the settings of the QoS profile as desired.
[00117] The communication of the application type across the system using application server (210) configuration may be explained in FIG. 5H. As shown in FIG. 5H, at step (520-1) UE (202) attach procedure / PDN establishment procedure completed and default QoS is assigned. At step (520-2), the application server (104) may perform application level configuration {IMEI, QCI, 5QI, Param1..N} with the network (208). At step (520-3), the network (106) may perform application level configuration {QCI, 5QI, Param1..N} with the UE (102). At step (520-4), UE (102) uses the newly set QoS profile and as well NW. And thus does the caching as per the set level (C1 … C6).
[00118] The communication of the application type across the system using AT command interfaces may be another way, where the application (108) in the IoT device (102) may communicate to the modem (110) on the application type and as well on the sensor data and its capability. Using these AT commands, modem (110) may become aware of the sensor capability, sensor data and as well the application type. Also, similar AT interface may be needed to send for any configuration sent by the network as needed by the application. Below are the set of the AT commands defined to be exchanged between modem and the application via the AT interface / port, such as:
AT%SENSORCMD
AT%SENSORDREQ
AT%SENSOREV
AT%SENSORCIND
AT%APPTYPE
AT%APPIND
AT%SENSORCMD
[00119] The possible responses for above commands is provided in Table 1 below.
Command Possible responses
%SENSORCMD=[,[,]] OK/ERROR
%SENSORCMD? Return list of available Capabilities:
%SENSORCMD: [ [,] ]
%SENSORCMD: < SensorType > [,]
…
%SENSORCMD: < SensorType > [,]
OK/ERROR
%SENSORCMD=?
%SENSORCMD: List of supported
Table 1
[00120] Description: AT command to manage SENSOR data / capability reception. Sent by application to the modem at power up or during a fresh session establishment.
[00121] Defined values: To share the Sensor data / Capability information of sensor device.
[00122] Description: This command is sent by the application on the first power on along with its capability and any sensor data available at that time.
[00123] Defined values:
:
“SENSOR_CAP” – Sharing the device capability information
:
:: { = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO …..} }
:
“SENSOR_DATA” – Requesting for the device Sensor data
:
:: { { = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO …..} , { = Array[][]}}
AT%SENSORREQ
[00124] The possible responses for above commands is provided in Table 2 below.

Command Possible responses
%SENSORREQ=[,[,]] OK/ERROR/%SESNORREQ:
%SENSORREQ? Return list of available Capabilities:
%SENSORREQ: [ [,] ]
%SENSORREQ: < SensorType > [,]
…
%SENSORREQ: < SensorType > [,]
OK/ERROR
%SENSORREQ=?
%SENSORREQ: List of supported

Table 2
[00125] Description: AT command to request SENSOR data / capability. The REQUEST is sent from the modem to the application.
[00126] Defined values: Obtaining Sensor data / Capability information of sensor device.
[00127] Description: This command is used by the modem to get the Sensor data and the sensor device’s capability. This shall be obtained by the modem before activating a particular session or during the first attach / TAU etc.
[00128] Defined values:
:
“REQUEST_CAP” – Requesting for the device capability information
:
Response will be :: { = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO …..} }
:
“REQUEST_SENSORDATA” – Requesting for the device Sensor data
:
Response will be :: { { = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO …..} , { = Array[][]}}
AT%SENSOREV
[00129] The possible responses for above commands is provided in Table 3 below.
Command Possible responses
AT%SESNSOREV= OK/ERROR
AT%SENSOREV? %SENSOREV:,
AT%SENSOREV=? %SENSOREV: List of supported

(unsolicited result code)
%SENSOREV: ,

Table 3
[00130] Description: This unsolicited command indicates the host that there are changes in the Sensor data affecting its services. Modem then query for additional data using AT%SENSORDREQ
[00131] Defined values
: a numeric parameter
1 – Enable unsolicited Sensor data indications
: a numeric parameter
0 – Sensor capability change indication
1 – Sensor data change indication
2 – Sensor type unavailable
3 – Sensor type available
3 -99 - Reserved
4 : string
0 – To be sent when event1 is anything other than 4.
AT%SENSORCIND
[00132] The possible responses for above commands is provided in Table 4 below.

Command Possible responses
%SENSORCIND=[,[,]] OK/ERROR
%SENSORCIND? OK/ERROR
%SENSORCIND=?
%SENSORCIND: List of supported

Table 4
[00133] Description: AT command to share the configuration information by the modem to the Application when sent by the Application server or the network related to the application.
[00134] Defined values: Obtaining Sensor configuration information of sensor device.
[00135] Description: This command is used by the modem to share the Sensor configuration data
[00136] Defined values:
:
“CONFIG_IND” – Indicating the Application level configuration change for the sensor device with param1.. N be the configuration parameters as defined by the network or the application server
:
OK / ERROR
AT%APPTYPE
[00137] The possible responses for above commands is provided in Table 5 below.
Command Possible responses
% =[,[,]] OK/ERROR
% APPTYPE? OK/ERROR
% APPTYPE =?
% APPTYPE: List of supported

Table 5
[00138] Description: AT command to share the application type along with its attributes to the modem as sent by the Application.
[00139] Defined values: Modem Obtaining application type information by the Application.
[00140] Description: This command is used by the application to let modem know the Application type.
[00141] Defined values:
:
“APP_TYPE” – Indicating the Application level configuration of the IoT device with param1.. N be the configuration parameters as defined by the network or the application server
Param 1…N indicate the type or attributes like –
Latency Sensitive
Latency Insensitive
Busty traffic
Random Wakeup
High and Instant TP Required
Guaranteed delivery
Etc
:
OK / ERROR
AT%APPIND
[00142] The possible responses for above commands is provided in Table 6 below.
Command Possible responses
% APPIND =[,[,]] OK/ERROR
% APPIND? OK/ERROR
% APPIND =?
% APPIND: List of supported

Table 6
[00143] Description: AT command to share the configuration information by the modem to the Application when sent by the Application server or the network related to the application. It can be
[00144] Defined values: Obtaining application side configuration information of IoT device.
[00145] Description: This command is used by the modem to share the application configuration data.
[00146] Defined values:
:
“APP_Config” – Indicating the Application level configuration change for the sensor device with param1.. N be the configuration parameters as defined by the network or the application server (210).
Param –
Latency Sensitive
Latency Insensitive
Busty traffic
Random Wakeup
High and Instant TP Required
Guaranteed delivery, Etc
:
OK / ERROR
[00147] Referring to FIG. 5I illustrates an exemplary sequence diagram representation of Application Type (AT) commands in Fifth Generation (5G) network architecture, in accordance with an embodiment of the present disclosure.
[00148] At step (522-1), the UE may be registered on the network. At step (522-2), the application (108) may application type (latency sensitive) is transmitted to modem (110). At step (522-3) the modem (110) may transmit PDU establishment request to the RAN (402). At step (522-4), the modem (110) may transmit Radio Resource Control (RRC) connection request to the RAN (402). At step (522-5), the RAN (402) may transmit back RRC connection acknowledgment to the modem (110). At step (522-6), the AMF (404) may perform SMF selection. At step (522-7), the AMF (404) may transmit Nsmf (i.e., Service-based interface exhibited by SMF) PDU session to create SM context request to the SMF (406).
[00149] At step (522-8), the SMF (406) may transmit back Nsmf PDU session to create SM response to the AMF (404).
[00150] At step (522-9) the SMF (406) may select Policy Control Function (PCF) an at step (522-10), the SMF (406) may modify SM initiated policy association including establishment cause, at step (522-11) the SMF (406) may select UPF. At step (522-12), the SMF (406) may transfer N1 N2 message to the AMF (404). At step (522-13) the AMF (404) may transmit PDU session request with new QFI to the RAN (402). At step (522-14), the RAN (402) may transmit PDU establishment acknowledgement to the modem (110). At step (522-15), the modem (110) may transmit AT% APPCIND to the application (108). At step (522-18), the message may be transferred between modem (110) and the DN (412).
[00151] FIG. 5J illustrates an exemplary sequence diagram representation of Application Type (AT) commands using a new Non-access stratum (NAS) in Fifth Generation (5G) network architecture, in accordance with an embodiment of the present disclosure.
[00152] At step (524-1), the UE (102) may be registered on the network. At step (524-2), the application (108) may application type (latency sensitive) is transmitted to modem (110). At step (524-3) the modem (110) may transmit PDU establishment request to the RAN (402). At step (524-4), the modem (110) may transmit Radio Resource Control (RRC) connection request to the RAN (402). At step (524-5), the RAN (402) may transmit back RRC connection acknowledgment to the modem (110). At step (524-6), the AMF (404) may perform SMF selection. At step (524-7), the AMF (404) may transmit Nsmf (i.e., Service-based interface exhibited by SMF) PDU session to create SM context request to the SMF (406).
[00153] At step (524-8), the SMF (406) may transmit back Nsmf PDU session to create SM response to the AMF (404). At step (524-9). At step (524-9) the AMF (404) may transmit set context request to the SMF (406). At step (524-10), the SMF (406) may transmit conformation on set context to the AMF (404). At step (524-11), the SMF (406) may select Policy Control Function (PCF) an at step (524-12), the SMF (406) may modify SM initiated policy association including establishment cause, at step (524-13) the SMF (406) may select UPF. At step (524-14), the SMF (406) may transfer N1 N2 message to the AMF (404). At step (524-15) the AMF (404) may transmit PDU session request with new QFI to the RAN (402). At step (524-16), the RAN (402) may transmit PDU establishment acknowledgement to the modem (110). At step (524-17), the modem (110) may transmit AT% APPCIND to the application (108). At step (524-18), the message may be transferred between modem (110) and the DN (412).
[00154] FIG. 5K illustrates an exemplary sequence diagram representation of Application Type (AT) commands using a new Non-access stratum (NAS) during lost User Equipment context/application type lost scenario during/ post-handover, in Fifth Generation (5G) network architecture, in accordance with an embodiment of the present disclosure.
[00155] At step (526-1), the UE (102) may be registered handover is performed. At step (526-2), the PCF may initiate SMF (406) to retrieve the context from UE (102). At step (526-3 to 526-11), the context from UE may be retrieved.
[00156] At step (526-12), the SMF (406) may modify SM initiated policy association including establishment cause, at step (526-13) the SMF (406) may select UPF. At step (526-14), the SMF (406) may transfer N1 N2 message to the AMF (404). At step (526-15) the AMF (404) may transmit PDU session request with new QFI to the RAN (402). At step (526-16), the RAN (402) may transmit PDU establishment acknowledgement to the modem (110). At step (526-17), the modem (110) may transmit AT% APPCIND to the application (108). At step (526-18), the message may be transferred between modem (110) and the DN (412).
[00157] In another embodiment, how the resource control can be achieved by the awareness of the sensor type, may be explained below:
RRC (Radio Resource Control) in the AS (Access Stratum) – part of the modem stack does a major role in resource and mobility management. Part of the RRC procedures – RRC maintain following 3 main states – RRC_IDLE, RRC_CONNECTED, RRC_INACTIVE.
RRC_IDLE: RRC connection is released
RRC_CONNECTION: An active session is going on – Data / Signaling
RRC_INACTIVE: An inactive period when active data transfer is done but the connection is still maintained in an anticipation of further data transfer.
[00158] However, in certain IoT use cases wherein the application needs to send only a fixed amount of data and there is nothing more to be sent later, then network can release the connection immediately and not keep the device in the RRC_INACTIVE state and thereby releasing the network resource.
[00159] For this to happen, UE (102) may need to send this specific information to the network (RAN) such that network using the existing mechanism indicate to the device as the RRC_Inactive_Timer as zero so that RRC connection shall be released immediately. Above information shall be passed by the UE to the RAN part of the capability information IE as seen below -

[00160] A new field UE-Sensor-Capability may be added to the UECapabilityInformation-NB object as follows:
UECapabilityInformation-NB ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE{
ueCapabilityInformation-r13 UECapabilityInformation-NB-r13-IEs,
criticalExtensionsFuture SEQUENCE {
UE-Sensor-Capability-NB SEQUENCE {
UEMobilitySensor,
ueFrequencySupport,
ueSensorType,
ueInactiveStateInd
}
}
}
}
[00161] The sensor capabilities could be added to the UE-Sensor-capability_NB sequence to aid the network to use to same for various efficiency use cases. In this embodiment the ability of the NB-IoT device to sense movement with aid of sensors is indicated – to the network under UE-Sensor-Capability-NB Sequence. This is represented by a Boolean flag ueMobilitySensor parameter in this proposal.
[00162] In yet another embodiment, the UE-Sensor-capability_NB can also contain the sensor type ex: an accelerometer or a gyroscope or a GPS or any such sensor and in one embodiment the measurement reports can also contain the readings from such sensors. This helps in the transmission of the sensor data via the measurement reports itself. The network then will route the data to the appropriate destination server based on apriory knowledge or through an APN/destination address indication. This helps in achieving early transmission mechanism and provides a data path for a sensor device. The network can schedule the measurement report periodicity and thus restrict the amount of information that the device can send.
[00163] In yet another embodiment the UE capability can also include the frequencies supported by the device. Supporting very specific frequencies (Ex: Band 3 or Band 5 only) can help in the measurement optimization and also saves battery power. This can also help the network to optimize handovers when the device can be maintained in a cell for as long as possible.
[00164] In yet another embodiment the UE (sensor device) can also include its capability to let the network know about its transmission pattern i.e. fixed bytes with fixed pattern so that inactivity timer and states can be configured accordingly. This can be achieved using a Boolean flag – ueInactiveStateInd which represents if the UE would need inactive state configuration or it can complete the transaction post transmission of the last packet.
[00165] To Indicate the last packet, a bit is indicated in the RLC header. Such information may be captured in the UE capability information element. As an example embodiment after adding the mobility sensor information, the UE capability information for NB-IoT looks like the following as described below.
UE-Capability-NB-rxx ::= SEQUENCE {
accessStratumRelease-r13 AccessStratumRelease-NB-r13,
ue-Category-NB-r13 ENUMERATED {nb1} OPTIONAL,
multipleDRB-r13 ENUMERATED {supported} OPTIONAL,
pdcp-Parameters-r13 PDCP-Parameters-NB-r13 OPTIONAL,
phyLayerParameters-r13 PhyLayerParameters-NB-r13,
rf-Parameters-r13 RF-Parameters-NB-r13,
sensor-Parameters-NB-rxx Sensor-Parameters-NB-rxx,
dummy SEQUENCE {} OPTIONAL
}
Sensor-Parameters-NB-rxx ::= SEQUENCE {
supported-sensor-list-rxx Supported-Sensor-List-NB-rxx,
mobility-management-need-rxx ENUMERATED {Stationary, Nomadic, Low Mobile, Full mobile} DEFAULT Stationary,
}
Supported-Sensor-List-NB-rxx ::= SEQUENCE (SIZE (1.. maxSensorsSupported-NB-rxx)) OF Supported-Sensor-NB-rxx
Supported-Sensor-NB-rxx ::= SEQUENCE {
sensor-ID INTEGER (0..255),
sensor-type ENUMERATED {Energy Meter, Water Meter, Gas Meter, Altimeter, pH meter, Soil Moisture Sensor, …},
sensor-specific-capability-NB-rxx Sensor-Specific-Capability-NB-rxx,
}
ueInactiveStateInd ::= {True, False}
[00166] It has to be understood that additional sensor types like Agriculture sensors can be added into the structure in a similar manner and the provided example is but one exemplary sample.
[00167] FIG. 6 illustrates an exemplary computer system 600 in which or with which embodiments of the present invention can be utilized in accordance with embodiments of the present disclosure. As shown in FIG. 6, computer system 600 can include an external storage device 610, a bus 620, a main memory 630, a read only memory 640, a mass storage device 650, communication port 660, and a processor 670. A person skilled in the art will appreciate that the computer system may include more than one processor 670 and communication ports 660. Examples of processor 670 include, but are not limited to, an Intel® Itanium® or Itanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), Motorola® lines of processors, FortiSOC™ system on chip processors or other future processors. Processor 670 may include various modules associated with embodiments of the present invention. Communication port 660 can be any of an RS-232 port for use with a modem based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. Communication port 660 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which computer system connects. The main memory 630 can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory 640 can be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or BIOS instructions for processor 670. Mass storage 650 may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), e.g. those available from Seagate (e.g., the Seagate Barracuda 782 family) or Hitachi (e.g., the Hitachi Deskstar 13K800), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks (e.g., SATA arrays), available from various vendors including Dot Hill Systems Corp., LaCie, Nexsan Technologies, Inc. and Enhance Technology, Inc.
[00168] Bus 620 communicatively couples processor(s) 670 with the other memory, storage and communication blocks. Bus 620 can be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects processor 670 to software system.
[00169] Optionally, operator and administrative interfaces, e.g. a display, keyboard, and a cursor control device, may also be coupled to bus 620 to support direct operator interaction with a computer system. Other operator and administrative interfaces can be provided through network connections connected through communication port 660. The external storage device 610 can be any kind of external hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.
[00170] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other changes in the preferred embodiments of the invention will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the invention and not as limitation.

ADVANTAGES OF THE PRESENT DISCLOSURE
[00171] The present disclosure provides systems and methods for efficient, latency sensitivity, and reliable optimizing of Quality of Service (QoS) in an Internet of Things (IoT) network.
[00172] The present disclosure provides systems and methods for new QoS profiles that will help identify if an application is latency insensitive, needs caching support and /or federated processing capabilities at the EDGE and or the radio access nodes.
[00173] The present disclosure provides systems and methods to support additional compute entities in the radio access network that may perform intelligent data processing for the specific applications.
[00174] The present disclosure provides systems and methods that is aware of the IOT application category or type which will then be used by the IOT network to appropriately assign new QoS classes appropriately.
[00175] The present disclosure provides systems and methods for signalling to change priorities between the category types as some application priorities are relative (Ex: from latency insensitive to latency sensitive types).
[00176] The present disclosure provides systems and methods which utilizes modem interface between the applications to the Non-Access stratum (NAS) that can map the new application categories to the defined new QoS class identifiers.
[00177] The present disclosure provides systems and methods for treating IoT applications / data based its overall end use case attributes in terms of reliability, latency sensitivity.
[00178] The present disclosure provides systems and methods to involve Qos parameters such as, data stream, packet of data or any data originating from a device needs caching, the locality of caching, if it needs local processing the nature of processing details.
[00179] The present disclosure provides systems and methods for a QoS mechanism of extended QoS template, the mechanism of interpreting and applying such a new QoS template for latency insensitive applications.
,CLAIMS:1. A system for allocating network resources based on a Quality of Service (QoS) profile of a User Equipment (UE) in an Internet of Things (IoT) network, the system comprising:
a processor;
an analysis engine coupled to the processor, wherein the analysis engine is to:
receive a request from a User Equipment (UE), wherein the UE is in communication with the system, over a network, and wherein the received request from the UE comprises a set of UE parameters;
extract the set of UE parameters from the received request;
based on the extracted set of UE parameters, assign a Quality of Service (QoS) profile to the request; and
based on the assigned QoS profile, allocate at least one of a plurality of network resources to the UE generating the request.
2. The system as claimed in claim 1, wherein the request is received from the UE through a communications modem, wherein the communications
modem is communicatively coupled to the UE and the system, over the network.
3. The system as claimed in claim 1, wherein the analysis engine is to further:
based on the received request from the UE, over the network, establish a Protocol Data Unit (PDU) session with the UE.
4. The system as claimed in claim 1, wherein the analysis engine, based on the extracted set of UE parameters, is to assign the QoS profile to the request, based on a pre-defined mapping criteria.
5. The system as claimed in claim 1, wherein the analysis engine is to:
based on the extracted set of UE parameters, categorise the request from the UE to be one of a latency sensitive request and a latency insensitive request.
6. The system as claimed in claim 1, wherein the plurality of network resources allocated to the UE generating the request comprises one of an allocation of processing resources, allocation of memory resources, assigning priority level of execution, or a combination thereof.
7. The system as claimed in claim 6, wherein the analysis engine, to allocate the processing resources, to the UE, is to:
cause the UE generating the request to utilize one of a plurality of processing resources of one of a plurality of entities in the network.
8. The system as claimed in claim 6, wherein the analysis engine, to allocate the memory resources, to the UE, is to:
cause the UE generating the request to utilize one of a plurality of cache memories of one of a plurality of entities in the network.
9. The system as claimed in claim 6, wherein the analysis engine, to assign priority level of execution, to the UE, is to cause a delay in executing the
request for a certain period of time.
10. The system as claimed in claim 1, wherein the set of UE parameters comprise one of a sensor data, an application data, or a combination thereof.
11. The system as claimed in claim 10, wherein the sensor data is obtained from one of a plurality of sensors in communication with the UE.
12. The system as claimed in claim 10, wherein the application data is obtained from an application executing on the UE.
13. A method for allocating network resources based on a Quality of Service (QoS) profile of a User Equipment (UE) in an Internet of Things (IoT) network, the method comprising:
receiving, by an analysis engine, a request from a User Equipment (UE), wherein the UE is in communication with the system, over a network, and wherein the received request from the UE comprises a set of UE parameters;
extracting, by the analysis engine, the set of UE parameters from the received request;
based on the extracted set of UE parameters, assigning, by the analysis engine, a Quality of Service (QoS) profile to the request; and
based on the assigned QoS profile, allocating, by the analysis engnie, at least one of a plurality of network resources to the UE generating the request.
14. The method as claimed in claim 13, wherein receiving, by the analysis engine, the request from the UE comprises receiving the request through a communications modem, wherein the communications modem is communicatively coupled to the UE and the system, over the network.
15. The method as claimed in claim 13, further comprising:
based on the received request from the UE, over the network,
establishing a Protocol Data Unit (PDU) session with the UE.
16. The method as claimed in claim 13, wherein assigning, by the analysis engine, the QoS profile, based on the extracted set of UE parameters, is based on a pre-defined mapping criteria.
17. The method as claimed in claim 13, further comprising:
based on the extracted set of UE parameters, categorising the request from the UE to be one of a latency sensitive request and a latency insensitive request.
18. The method as claimed in claim 13, wherein allocating the plurality of network resources to the UE generating the request comprises allocating processing resources, allocating memory resources, assigning priority level
of execution, or a combination thereof.

19. The method as claimed in claim 18, wherein allocating the processing resources to the UE, by the analysis engine, comprises:
causing the UE generating the request to utilize one of a plurality of processing resources of one of a plurality of entities in the network.
20. The method as claimed in claim 18, wherein allocating the memory resources to the UE, by the analysis engine, comprises:
causing the UE generating the request to utilize one of a plurality of cache memories of one of a plurality of entities in the network.
21. The method as claimed in claim 18, wherein assigning priority level of execution to the UE, by the analysis engine, comprising causing a delay in executing the request for a certain period of time.
22. The method as claimed in claim 13, wherein the set of UE parameters comprise one of a sensor data, an application data, or a combination thereof.
23. The method as claimed in claim 22, wherein the sensor data is obtained from one of a plurality of sensors in communication with the UE.
24. The method as claimed in claim 22, wherein the application data is obtained from an application executing on the UE.