Handover with QoS. The technology-neutral QoSAPI exposed by the policy/QoS agent module provides an opportunity for higher layer applicationsto request the creation/deletion of certain QoSflows for those devices and RATs that support UEinitiated QoS flow setup. One of the benefits ofproviding this QoS API is that higher layer applications do not need to be concerned about thespecifics of how QoS flows are established foreach of the different access technologies. It has asingle, consistent view of how to request QoSspecific flows. The CM, along with the deviceadapter APIs, provide the necessary translation ofQoS parameters in order to create/delete a specificQoS flow. The capability of the RAT to supportUE-initiated QoS flow setup is communicated asa policy to the CM. As discussed above, support ofhandovers with QoS between heterogeneousaccess networks, where one of the networks hasa UE-initiated QoS flow setup and another has anetwork-initiated QoS flow setup, requires cooperation between the PCC function and the UE (inaddition to a common PCC function in the network). In the WISH IWCM architecture, suchcooperation is a function of the CM and deviceadapter, using the device adapter API to retrievethe currently configured QoS flows and to establishspecific QoS flows. For example, when handing over from an access technology that supports network-initiated QoS flow setup to an accesstechnology that supports a client-initiated QoSflow setup, CM can (in a make-before-break fashion) retrieve the current settings from the sourceaccess technology device adapter, map theretrieved QoS flow profile to the target accesstechnology, and then establish (as part of themake-before-break handover procedure) the corresponding QoS flow on the target access technology
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Note: only a member of this blog may post a comment.