 packet core network but performs some of the fundamental functions and hosts some of the fundamental data for operation of the network. The HLR, one of the core network nodes, definitely plays a major role in the QoS process. It hosts all the QoS relevant parameters from a subscription point of view, at two levels: firstly, on a subscriber basis (which are determined combinations of QoS parameters), and, secondly, on an application basis (which are the QoS parameters required for a given application), normally defined per APN. The QoS parameters stored in the HLR are used during activation of the PDP context and are thus utilised for the duration of it, unless a PDP context modification takes place. When designing new services, the service subscription data stored in the HLR has to be carefully analysed. A simplified structure of the QoS parameters is required in order to deal with the complexity of the possible combinations. Normally, a given set of parameters that are meaningful for that given application will be created as a QoS template or QoS profile, and that template will be re-used for a group of subscribers (e.g. premium, normal or prepaid) when using the given application (e.g. browsing, messaging or streaming). Thus, when a premium subscriber invokes a streaming service, he/she will be granted a PDP context with a certain set of parameters, which can be slightly different from those granted for a prepaid subscriber when using that service if the operator has SO defined the access differentiation. Alternatively, the data can be structured SO that the differentiation is performed only based on the application. Since the only application data available in the HLR is the APN, it can be problematic to introduce QoS differentiation when more than one application shares a common APN. The problem can obviously be solved by allocating a dedicated APN per application. This solution, in turn, leaves the subscriber with a provisioning problem, giving him/her the responsibility of selecting the correct APN when us