11.5 Dynamic Service Addition and Change

11.5.1 Service Flow Provisioning and Activation

A service flow that has a non-Null ActiveQoS ParamSet is said to be an active service flow (see Section 7.2.2). This service flow may request and be granted a bandwidth for the transport of data packets. An admitted service flow may be activated by providing an ActiveQoSParamSet, signalling the resources desired at the current time.

A service flow may be provisioned and then activated. Alternatively, a service flow may be created dynamically and immediately activated (see Figure 11.14). In this latter case, the two-phase activation is skipped and the service flow is available for immediate use upon authorisation.

image from book
Figure 11.14: Possible transitions between service flows. A BS may choose to activate a provisioned service flow directly or may choose to take the path to active service flows passing by the admitted service flows

The provisioning of service flows is outside the scope of the 802.16 standard. This should be part of the network management system. During provisioning, a service flow is classified, given a ‘provisioned’ flow type and a service flow ID. Enabling service flows follow the transfer of the operational parameters. In this case, the service flow type may change to ‘admitted’ or to ‘active’; in the latter case, the service flow is mapped on to a certain connection.

Service flows may be created, changed or deleted. This is accomplished through a series of MAC management messages:

DSA (Dynamic Service Addition) messages create a new service flow;
DSC (Dynamic Service Change) messages change an existing service flow;
DSD (Dynamic Service Delete) messages delete an existing service flow. This is illustrated in Figure 11.15.

Figure 11.15: Dynamic service flow operations. (Based on Reference ^[1].)

For some service flows, it may be specified that the DSA (Dynamic Service Addition) procedure used for service flow creation must be activated by the network entry procedure. Triggers other than network entry may also cause creation, admission or activation of service flows. These triggers are said to be outside the scope of the standard. Service flow encodings contain either a full definition of service attributes or a service class name. A service class name must be an ASCII string, which is known at the BS and which indirectly specifies a set of QoS parameters.

11.5.2 Service Flow Creation

Creation of a service flow may be initiated by either the BS (mandatory capability) or the SS (optional capability). The DSA messages are used to create a new service flow. Since it is a new service flow, the primary management CID is used to establish it. This CID value is used in the generic MAC header of DSA messages.

A DSA-REQ, DSA REQuest MAC management message from an SS, wishing to create either an uplink or downlink service flow, contains a service flow reference and a QoS parameter set, marked either for admission-only or for admission and activation. A DSA-REQ from a BS contains an SFID for either one uplink or one downlink service flow, possibly its associated CID, and a set of active or admitted QoS parameters. In both cases, the BS checks successively the following points:

whether the SS is authorised for service;
whether the service flow(s) QoS can be supported;

and then possibly creates SFID and, if AdmittedQoSParamSet is non-null, maps the service flow to a CID. The BS or the SS responds with the DSA-RSP, DSA Response, MAC management message, indicating acceptance or rejection. Figure 11.16 shows the service flow creation procedure messages.

image from book
Figure 11.16: Successful service flow creation procedure messages and attributes. Some of the parameters in this figure are not included in some DSx messages depending on whether the service creation is BS or SS initiated. (Figure from Reference ^[1] modified by G. Assaf.)

For DSA-REQ and DSC-REQ messages sent by an SS, the DSX-RVD (DSx Received) message is generated by the BS to inform the SS that the BS has correctly received the DSx-REQ message. This can be done quickly before sending the DSx-RSP message, which is transmitted only after the DSx-REQ is authenticated.

The general format of DSA-REQ, DSA-RSP and DSA-ACK messages is shown in Figure 11.17. The DSA-REQ message cannot contain parameters for more than one service flow. The transaction ID is a unique identifier for this transaction assigned by the sender. The confirmation code indicates the status for the dynamic service (DSx-xxx) messages. Possible values are: OK-success, reject, reject-service-flow-exists, reject-header-suppression, reject-authentication-failure, etc.

Management message type (=11, 12 or 13)

Transaction ID

Confirmation code (Only DSA RSP and ACK)

TLV encoded information

Figure 11.17: The general format of DSA-REQ, DSA-RSP and DSA-ACK MAC management messages

The TLV encoded information field contains the specification of the service flow's traffic characteristics, CS specific parameters and scheduling requirements. These parameters are:

CID:specifies the CID assigned by the BS to a service flow. The CID is used in bandwidth requests and in MAC PDU headers.
SFID: the primary reference of a service flow. Only the BS may issue an SFID in BS-initiated DSA-REQ/DSC-REQ messages and in its DSA-RSP/DSC-RSP to SS-initiated DSA-REQ/DSC-REQ messages. The SS specifies the SFID of a service flow using this parameter in a DSC-REQ message.
Service class name: see Section 11.5.1 above.
QoS parameter set type: provisioned, admitted or active.
Traffic priority. The value of this parameter specifies the priority assigned to a service flow. Given two service flows identical in all QoS parameters besides priority, the higher priority service flow should be given lower delay and higher buffering preference. For nonidentical service flows, the priority parameter should not take precedence over any conflicting service flow QoS parameter. No specific algorithm for using this parameter is given in the standard. For uplink service flows, the BS uses this parameter when determining precedence in request service and grant generation.
Scheduling service type. This is the one that should be enabled for the associated service flow, between the five defined scheduling service types: BE (default), nrtPS, rtPS, ertPS or UGS. If this parameter is omitted, BE service is assumed. An undefined scheduling service type (implementation-dependent) can also be set.
Other QoS parameters: maximum sustained traffic rate, maximum traffic burst, minimum reserved traffic rate, minimum tolerable traffic rate, ARQ parameters for ARQ-enabled connections, etc. (see QoS parameters in Section 7.4).
Target SAID (Security Association IDentifier). This indicates the SAID on to which the service flow that is being set up will be mapped. The SAID is a security association identifier shared between the BS and the SS (see Chapter 15).
CS specification. This specifies the CS that the connection being set up will use. Possible choices are No CS, Packet IPv4, Packet IPv6, Packet 802.3/Ethernet, Packet 802.1Q VLAN, Packet IPv4 over 802.3/Ethernet, Packet IPv6 over 802.3/Ethernet, Packet IPv4 over 802.1Q VLAN, Packet IPv6 over 802.1Q VLAN and ATM.

11.5.3 Service Flow Modification and Deletion

Both provisioned and dynamically created service flows are modified with the DSC message, which can change the admitted and active QoS parameter sets of the flow. A single DSC message exchange can modify the parameters of either one downlink service flow or one uplink service flow.

A successful DSC transaction changes the service flow QoS parameters by replacing both the admitted and active QoS parameter sets. If the message contains only the admitted set, the active set is set to null and the flow is deactivated. If the message contains neither set, then both sets are set to null and the flow is de-admitted. When the message contains both QoS parameter sets, the admitted set is checked first and, if the admission control succeeds, the active set in the message is checked against the admitted set in the message to ensure that it is a subset. If all checks are successful, the QoS parameter sets in the message become the new admitted and active QoS parameter sets for the service flow. If either of the checks fails, the DSC transaction fails and the service flow QoS parameter sets are unchanged. Some service flow parameters, including the service flow scheduling type, may not be changed with the DSC messages.

An SS wishing to delete a service flow generates the DSD-REQuest message to the BS. The BS verifies that the SS is really the service flow ‘owner’ and then removes the service flow. The BS responds using the DSD-RSP message. On the other hand, a BS wishing to delete a dynamic service flow, no longer needed, generates a delete request to the associated SS using a DSD-REQuest. The SS removes the service flow and generates a response using a DSD-RSP.

11.5.4 Authorisation Module

The authorisation module is a logical function within the BS that approves or denies every change to QoS parameters and classifiers associated with a service flow. This includes every DSA-REQ message aiming to create a new service flow and every DSC-REQ message aiming to change a QoS parameter set of an existing service flow. Such changes include requesting an admission control decision (e.g. setting the AdmittedQoSParamSet) and requesting activation of a service flow (e.g. setting the ActiveQoSParamSet).

In the static authorisation model, the authorisation module stores the provisioned status of all deferred service flows. Admission and activation requests for these provisioned service flows are permitted as long as the admitted QoS parameter set is a subset of the provisioned QoS parameter set and the active QoS parameter set is a subset of the admitted QoS parameter set. Requests to change the provisioned QoS parameter set are refused. Requests to create new dynamic service flows are refused. This defines a static system where all possible services are defined in the initial configuration of each SS.

In the dynamic authorisation model, the authorisation module communicates through a separate interface to an independent policy server. This policy server may provide the authorisation module with advance notice of upcoming admission and activation requests, and it specifies the proper authorisation action to be taken on those requests. Admission and activation requests from an SS are then checked by the authorisation module to ensure that the ActiveQoSParamSet being requested is a subset of the set provided by the policy server. Admission and activation requests from an SS that are signalled in advance by the external policy server are permitted. Admission and activation requests from an SS that are not presignalled by the external policy server may result in a real-time query to the policy server or may be refused.

Prior to the initial connection setup, the BS retrieves the provisioned QoS set for an SS. This is handed to the authorisation module within the BS. The BS caches the provisioned QoS parameter set and uses this information to authorise dynamic flows that are a subset of the provisioned QoS parameter set. The standard states that the BS should implement mechanisms for overriding this automated approval process (such as described in the dynamic authorisation model). For example it could:

deny all requests whether or not they have been pre-provisioned;
define an internal table with a richer policy mechanism but seeded by the provisioned QoS set;
refer all requests to an external policy server.