Patent Application
20140029534
This application which claims the benefit of Ser. No. 201231230, filed 30 Jul. 2012 in Spain, and is hereby incorporated by reference in its entirety. To the extent appropriate, a claim of priority is made to the above disclosed application.
The present disclosure has its application within the field of telecommunications.
The introduction of smartphones has strongly increased the level of variety of services and type of user experience within the mobile world; as an example, the type and version of the operating system, the phone model, the characteristics of the installed applications in the smartphone and the type of web pages navigated by the end user all contribute to provide a different set of requirements towards the Network in terms of single connection optimization as well as overload management.
A central point of network optimization is the UTRAN. According to the 3GPP standard TS 25.301 only access-layer information is well known by BSC/RNCs and LTE eNodeBs, whilst, instead, a big amount of useful information for optimization is contained in the so called Application Layer or Non-Access Stratum layer.
Access Network optimization therefore becomes an increasingly complex task since access is blind on a huge amount of information available at the end user terminal.
The present disclosure refers to a method for delivering information to a Radio Access Network, to a network entity of the Radio Access Network and to a user equipment for delivering information to a Radio Access Network according to claims 1, 14 and 17, respectively. Preferred embodiments of the method and the network entity are defined in the dependent claims.
The method according to the present disclosure serves to solve the aforesaid problem by providing a network entity of the Radio Access Network with specific user equipment (UE) information in order to optimise the use of radio resources.
A first aspect relates to a method for delivering information to a Radio Access Network, RAN, of a telecommunications network, comprising the following steps:
Said application for collecting information is preferably a software application such as a widget.
The information collected and delivered to the Radio Access Network is preferably application layer data or non-access stratum layer data.
The application is preferably preloaded in the user equipment. Alternatively, the method further comprises a previous step of downloading the application, or the application can be executed in real-time.
The step of encapsulating the information collected by the application in a packet preferably comprises adding a header of a transport protocol, preferably selected from TCP or UDP. Preferably a specific IP address defined by a network operator and a given port number are also included in the packet.
The step of detecting the packet by the network entity of the Radio Access Network preferably comprises shallow packet inspection. This step preferably comprises comparing the IP address and the port number in the packet with the ones defined by a network operator.
The current method provides the means for transferring information to the Radio Access Network, which information can be used in order to fine tune several network parameters like: channel type change, mobility thresholds, or even application information customisation, etc.
According to preferred embodiments, the step of configuring a set of Radio Access Network parameters by the network entity of the Radio Access Network may comprise one or more of the following:
A second aspect refers to a network entity of a Radio Access Network of a telecommunications network, comprising:
Detecting the packet preferably comprises shallow packet inspection.
The step of detecting the packet preferably comprises comparing an IP address and a port number included in the packet with an IP address and port number defined by a network operator.
The information retrieved the Radio Access Network entity preferably is either application layer information or non-access stratum layer information.
A third aspect relates to a user equipment for delivering information to a Radio Access Network of a telecommunications network, the user equipment comprising:
The user equipment may include storing means for storing the application for collecting information, which application is previously downloaded in the user equipment. Alternatively, the application can be executed in real-time.
In the present disclosure, the Radio Access Network can be 3G or LTE.
These and other aspects will be apparent from and elucidated with reference to the embodiment described hereinafter.
To complete the description and in order to provide for a better understanding of the present disclosure, a drawing is provided. The drawing forms an integral part of the description and illustrates the preferred embodiments, which should not be interpreted as restricting the scope of the claims, but just as an example of how the present disclosure can be embodied.
The drawing comprises
According to a preferred embodiment of the present disclosure as shown in
The packet 100 contains a header 110 of a predefined transport protocol (TCP or UDP), specifying a predefined IP target address and a predefined port number to mark the packet as generated by the widget, so as to distinguish it from standard user plane packets 100′. In the example shown in
The packet 100 also contains the following relevant information 120 of the smartphone: IMEI, manufacturer, model, screen size, SW version, launched or running applications, GPS location.
The packet 100 is then sent (step s102), together with the rest of standard packets 100′ to a core network 40 via the corresponding Radio Access Network, RAN.
The Node B 20/ Radio Network Controller, RNC 30 (or an eNodeB in LTE) uses shallow packet inspection (step s103) to analyze the user plane Uplink traffic sent through a specific Radio Access Bearer.
When the target IP address and port number in the header 110 of the widget are identified as the target combination of IP address and port as defined by the network operator, the information 120 within the packet 100 is read (s104).
The RNC 30 then compares the values of the information received with a set of RAN parameters contained in a parameter database 50, and selects (s105) appropriate values to be applied for managing the ongoing packet connection.
As shown in
Screen size=2
SW version=4.0.3
App=YouTube
The RNC then consults the parameter database 50, which in the present case has the following parameters:
No info=default parameters
Screen size=1->QoS=1
Screen size=2->QoS=2
Screen size=x->QoS=z
SW version<=3.0->default CELL PCH timer
SW version=>4.0->CELL PCH timer=3 s.
App=YouTube->Max throughput=1 Mbps
App=Joyn->QoS=Max
As a result, the RNC establishes the following values for the ongoing connection:
QoS=2
CELL PCH timer=3 s
Max throughput=1 Mbps, thereby improving the experience of the user who has ran the widget on his/her smartphone.
The pieces of information communicated to the BSC/RNC or eNodeB can be one or more of the following:
This includes information about the user equipment, particularly regarding the one or more of the hardware, operating system, firmware, software and location of the user equipment. This information is collected using an application (such as a widget) operative on the user equipment.
Based on the received information the RNC or eNodeB is able to modify one or more of the following:
As indicated above, with the information received from the terminal (or user equipment), the network entity is able to modify parameters of the Radio Access Network, which may comprise one or more of physical layer parameters, data link layer parameters, network layer parameters and transport layer parameters. These may include parameters of the radio access network interface and Internet Protocol (IP) parameters. In particular, the network entity is able to modify the timers for switching channels to go from dedicated state DCH, in which a channel is allocated to the user, to a non-dedicated state.
For example, if the terminal is a smartphone, it is well known that smartphones are usually more limited by the battery consumption; therefore, the timers from dedicated to non-dedicated can be made shorter for this kind of devices. Tablets are not so battery-critical, so timers can be longer. And USB dongles connected to a PC do not have any battery limitation, so timers can be even longer.
In 3G the use of the Fast Dormancy feature by smartphones is quite well known. Every terminal manufacturer implements this FD feature with different timers. This FD basically consists in the disconnection from the network when the terminal does not have any more data to transmit. Then, having the information of the IMEI and the OS software version, it is possible to know the value of the timers for Fast Dormancy, and then the network is able to go to a more efficient channel state (like URA_PCH or Cell_PCH) before the terminal requests the disconnection due to the FD feature.
In 3G there are four different channel states:
By means of the information provided by the widget, the BSC/RNC can configure the timers to go from one of the previous states to the other.
In LTE there are just two states: connected and idle mode. Thus, with the terminal information that has been received, the eNodeB can modify the timer to switch between connected and idle mode.
Also, the QoS (Quality of Service) differentiation, i.e. the distribution of RAN resources based on user priority, can be differently set depending on the terminal information. For example:
Overload control policies are in charge of discarding connections and/or traffic in case any part of the RAN network is congested. In the present case these policies can be modified to start the discarding of connections by the most active phones.
For example, if the signalling processing boards are congested, then it is necessary to control the terminal which is producing more signalling. There are statistics per terminal in the network, so that it is possible to configure the RNC to start rejecting calls from some specific models.
It is known that the parameters of a RAB, namely the maximum bandwidth and the allowed frame sizes, can be configured according to the requirements of the application using it. Thus, with the information received it is possible to avoid assigning specific RAB combinations which are known to create issues with specific terminal types.
Also, traditional transcoding (or adaptation) on multimedia has been performed from the perspective of user terminal capabilities such as display sizes and decoding processing power. Then, the functions of the content optimization in the RAN control the downloaded content (as for example, web pages) depending on the radio conditions and load. This functionality can have a content adaptation to the screen size which depends on the screen & display size information obtained from the terminal.
Depending on the screen size (pixels) of the terminal, the quality of a video perceived by the customer is different. The functions of video optimization in the RAN control the video coding depending on the radio conditions and load. This functionality can have a minimum and maximum quality ranges which depend on the size information obtained from the terminal.
Another example is to use the OS model to change this video optimization function. The quality requested for the YouTube application running on an iPhone or an iPad is low in 2G/3G networks, and high in WiFi networks. In case the network is able to support the high bit rate, the RAN can modify the quality requested by the UE to the video server knowing that it is an iPhone/iPad requesting high quality.
Additionally, all the information sent by the terminal can be statistically analysed in order to optimize the network in the future. For example:
Therefore, by means of the present disclosure the Radio Access Network can become much smarter in managing user experience and overload.
The application may be installed on the terminal and configured to run on the terminal for collecting information as described above. The information may include, for example, the IMEI of the terminal and other type of useful terminal information as described above. This information may be encapsulated as described above (directly or indirectly by the application) and transmitted to the BSC/RNC or eNodeB as discussed above. In this way, the Radio Access Network (RAN) relies on the application at the terminal for obtaining information which is then used for optimization, rather than on standard mechanisms in order to retrieve information about the terminal. One advantage of an embodiment according to the present disclosure is that the RAN is capable of retrieving much more information from the terminal(s) than it would if it was to rely on standard mechanisms in order to retrieve information about the terminal(s). This, in return, enables the RAN to optimize the network more efficiently and effectively. For example, the RAN can apply different parameters for the radio algorithms as a function of the type of information received from the terminal (for example, the IMEI). As a variant, the RAN may also retrieve information about the terminal independently from the application (e.g., by using the standard mechanisms described above) and use this, for example, to confirm or supplement the info received from the application. Nevertheless, the RAN will still rely on the application to retrieve information from the terminal.
The present disclosure is obviously not limited to the specific embodiments described herein, but also encompasses any variations that may be considered by any person skilled in the art (for example, as regards the choice of components, configuration, etc.), within the general scope of the invention as defined in the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201231230 | Jul 2012 | ES | national |
