1.1. QoS (Quality of service) in MBMS Overview
MBMS QoS is a MBMS service attribute:
- MBMS data will be distributed to multiple users, so that the QoS cannot be associated to one UE in particular.
- It should be possible for the operator to collect statistical data such as lost frames, assigned resources, bit-rates achieved etc.
- It shall be possible for the operator to adapt the distribution of a MBMS user service consisting of different MBMS transport services to provide multiple QoS levels according to the QoS resources provided by the access network(s), while maintaining the resource efficiency of the underlying MBMS transport services.
- It shall be possible to adapt the distribution of an ongoing MBMS user service to persistently changed QoS resource conditions in the access network(s).
- It shall be possible to base the adaptation of the distribution of a MBMS user service to the QoS resources provided by the access network(s) on:
- the QoS resources within the same access network (e.g. UTRAN).
- the QoS resources provided by different access networks (e.g. UTRAN and GERAN).
- Adaptation of the distribution of a MBMS user service to the QoS resources in different access networks or parts of the same access network shall not affect the QoS of the MBMS user service in other access networks or other parts of the same access network.
It shall be possible for the network to control quality-of-service parameters for multicast and broadcast sessions. All QoS parameters described in shall be supported with the following changes:
- For traffic class, only the background and streaming classes shall be supported.
- For Background and streaming classes may have to be extended with a “priority” attribute (the Traffic Handling Priority may be reused for this purpose).
- The network could use this attribute to selectively drop packets from particular MBMS bearers (typically those providing the highest QoS) when the resources allocated to MBMS are nearing saturation.
Compared to point-to-point bearer services, the following limitations in MBMS exist:
- For traffic class, only the background and streaming classes shall be supported.
- For SDU error ratio, only higher values are supported, i.e. the values describing higher numbers of lost or corrupted SDUs (actual values are for the background and streaming classes are 10-2 and 10-1).
- For Maximum bit-rate, see the values described in TS 22.246.
- For Guaranteed bit rate of the Streaming Traffic Class: depending on radio resource usage by other services, some cells of the MBMS Service Area may not have sufficient resources available for a MBMS Session. The RAN may decide not to establish RB in cells where requested resources are not available.
Background Class:
MBMS bearer services of background class are best suited for the transport of MBMS user services such as messaging or downloading.
- Buffering, Shaping Schemes and Packet Dropping may be applied to the traffic flow to adapt to the available resources and changing network conditions. The total transfer time is not critical for background class bearer services since the content must normally have been received in totality and stored in the UE before the user can access it.
Streaming Class:
MBMS bearer services of streaming class are best suited for the transport of MBMS user services such as streaming.
- As for point-to-point bearer services, the network should minimise the packet transfer delay of streaming class bearer services as far as possible. Packet dropping should be the preferred traffic conditioning action applied to the traffic flow to adapt to the available resources.
The principle difference between background and streaming classes for MBMS is the support of a guaranteed bit-rate in the streaming case.
- No indication is provided to the UE in cases where the RAN cannot provide the requested QoS. As a result, some UEs may not receive the MBMS session or parts of it.
- For background class, the RAN may continue to distribute data in congestion conditions but at potentially high packet loss rates, therefore the MBMS user service will have to provide sufficient redundancy within the data to be able to cope with the high packet loss.
- MBMS user services that would normally use MBMS bearer services of background class may however decide to use a streaming class MBMS bearer service if the MBMS user service cannot cope with high packet loss.
- The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer services, and between MBMS bearer services and non MBMS bearer services.
- As the MBMS bearer service transfers data to many UEs in parallel and because of the lack of feedback channel on radio level low SDU error ratios are difficult to achieve.
- When the resulting packet error ratio is not suitable for the MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of MBMS data over a point-to-point PDP context
MBMS distribution tree and MBMS QoS distribution tree
- MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many BSCs/RNCs, many SGSNs and one or more GGSNs.
- Furthermore some transport resources may be shared between many users accessing the same service in order to save resources.
- As a result, each branch of a MBMS distribution tree shall be established with the same QoS. The MBMS distribution tree shall have the same QoS for all its branches.
- When a branch of the MBMS distribution tree has been created, it is not possible for another branch (e.g. due to arrival of a new UE or change of location of a UE with removal of a branch and addition of a new one) to impact the QoS of already established branches.
- There is no QoS (re-)negotiation between network elements (e.g. between RNC and SGSN). This implies that some branches may not be established if QoS requirement cannot be accepted by the concerned network node
- One of the consequences is that some branches may not be established if QoS requirement cannot be accepted by the concerned network node.
- QoS negotiation should not be allowed by UMTS network elements. QoS negotiation shall not be done by the network nodes. QoS re-negotiation feature in the RNC should not be allowed for MBMS service.
1.2. QoS Principles for Related Media Streams
Media components
- This is the case where the MBMS service requires several distinct types of data (e.g. audio & video) which require separate QoS within the UMTS network.
Four types of related media streams are considered:
1). Optional media streams – Lower Quality
- The MBMS service uses several streams of data. The service can still be offered (with lower quality) if some streams are not received. This is typically the case of hierarchical encoding schemes.
2). Alternative media streams (QoS) – Same media with different QoS
- The MBSM service requires exactly one of a particular set of data streams. The streams contain the same media, but with different QoS, e.g. bit-rate.
3). Alternative media streams (Geography) – Different media stream depended on location
- The MBMS service requires exactly one of a particular set of data streams. The streams contain different media and the stream required depends on the geographic location of the user
4). Multiple QoS Streams and Interfacing with the PDN
- The GGSN is used to capture MBMS data in the PDN and put this data on one or more GTP tunnels opened as part of the service.
- Different media components comprising a single MBMS service from a user’s point of view may provide over separate GTP tunnels and bearers enabling QoS differentiation for each component thru two options below.
- Both alternatives are supported by the session description protocol (SDP).
- As an example, this could be used when different media with different error protection requirements are transmitted (e.g. audio vs. visual streams or a base video stream with one or more enhancement layers).
- In some cases, a given MBMS service will be provided in multiple locations with inherently different QoS capabilities.
- As an example a service might be provided over the GERAN and the UTRAN access networks of the operator requiring the operator to provide a single service in more than one QoS profile, depending on the access network.
The different media components are transmitted either
Option 1. by using one IP multicast group but multiple ports (see option 1) or
Option 2. by using separate IP multicast groups (see option 2).
Option 1 - transmitted by using one IP multicast group but multiple ports
- To allow multiple media components per transmission, different components can be sent on different destination UDP ports but using the same destination IP multicast address.
- The GGSN, using TFTs, should be able to tunnel the data through the proper GTP tunnel using the UDP port value to for selecting between different tunnels.
- To allow for multiple QoS alternatives targeted at different locations, the GGSN should be able to map several alternative transmissions of different media components to different GTP tunnels. Transport of different QoS alternatives on the PDN is FFS.
Option 2 - transmitted by using separate IP multicast groups
- Different media components are transmitted on separate IP multicast groups, each identified by a different IP multicast address and requiring a specific Quality of Service handling.
- A number of GTP tunnels (MBMS bearer services) is set up, one for each destination IP multicast address, and the GGSN maintains a mapping from the IP multicast address to the corresponding GTP tunnel.
- To allow for multiple QoS alternatives, possibly targeted at different locations, different IP multicast addresses are also used.
- The GGSN is required to map several multicast/broadcast transmissions carried over several IP multicast addresses to the same number of distinct groups of GTP tunnels
1.3. Media Descriptions
- Different services may be offered with different combinations and alternatives of media.
- A service might consist of one or more media components (e.g. a video oriented service with a visual and audio component).
- Further, any service might be offered at any one time with different QoS depending on available resources in any given cell.
- To describe these services to potential applications on the UE (e.g. media players), a media description protocol should be used.
- The network and specifically the BM-SC should provide the UE application with the media description.
A media description should include at the very least:
- Relevant IP multicast address and APN for the service.
- Different possible media components for the service.
For the purpose of relaying media description parameter, SDP may be preferable as it is already being used in providing such services as IMS.
For each media component, the media description should include:
- UDP/IP ports over which the media component is sent and received,
- Media type (e.g. audio or video or data).
- Media formats (e.g. MPEG-4 or H.263).
1.4. QoS principles for Messaging Services
- A messaging service is characterised by its fixed, pre-determined size.
- A possible way to handle this kind of MBMS service could be to set the traffic class attribute for the corresponding GTP tunnel to Background and provision a small buffer in the RNS/BSS to shape the message transmission to the available bandwidth for MBMS traffic in the cell.
- Other quality of service bearer attributes, together with the resource situation, would only impact the transmission duration of the message, but not the amount of transmitted bytes.
- The RNS/BSS would not drop any packets. The buffer size could be either dynamically adapted or pre-configured or possibly requested by the BM-SC and would be applied only when the traffic class is set to Background.
- When the UE moves from one cell to another cell (mobility cse), the unsynchronised transmission between cells may result in part of the message being lost.
1.5. Quality of Service (QoS) Information Element
- The purpose of the quality of service information element is to specify the QoS parameters for a PDP context.
- The QoS IE is defined to allow backward compatibility to earlier version of Session Management Protocol.
- The quality of service is a type 4 information element with a minimum length of 14 octets and a maximum length of 18 octets. The QoS requested by the MS shall be encoded both in the QoS attributes specified in octets 3-5 and in the QoS attributes specified in octets 6-14.
- In the MS to network direction and in the network to MS direction the following applies:
- Octets 15-18 are optional. If octet 15 is included, then octet 16 shall also be included, and octets 17 and 18 may be included.
- If octet 17 is included, then octet 18 shall also be included.
- A QoS IE received without octets 6-18, without octets 14-18, without octets 15-18, or without octets 17-18 shall be accepted by the receiving entity.
- Figure: 3GPP TS 24.008: Quality of service information element
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | | ||||
| Quality of service IEI | octet 1 | |||||||||||
| Length of quality of service IE | Octet 2 | |||||||||||
| 0 0 | Delay | Reliability | octet 3 | |||||||||
| Peak | 0 | Precedence | octet 4 | |||||||||
| 0 0 0 | Mean | octet 5 | ||||||||||
| Traffic Class | Delivery order | Delivery of erroneous SDU | Octet 6 | |||||||||
| Maximum SDU size | Octet 7 | |||||||||||
| Maximum bit rate for uplink | Octet 8 | |||||||||||
| Maximum bit rate for downlink | Octet 9 | |||||||||||
| Residual BER | SDU error ratio | Octet 10 | ||||||||||
| Transfer delay | Traffic Handling priority | Octet 11 | ||||||||||
|
| Octet 12 | |||||||||||
| Guaranteed bit rate for downlink | Octet 13 | |||||||||||
| 0 0 0 | Signal-ling Indicat-ion | Source Statistics Descriptor | Octet 14 |
| |||||||||
| Maximum bit rate for downlink (extended) | Octet 15 | |||||||||||
| Guaranteed bit rate for downlink (extended) | Octet 16 | |||||||||||
| Maximum bit rate for uplink (extended) | Octet 17 | |||||||||||
| Guaranteed bit rate for uplink (extended) | Octet 18 | |||||||||||
Table - 3GPP TS 24.008: Quality of service information element
Reliability class, octet 3 (see 3GPP TS 23.107)
Bits
3 2
I
0 0 0 Subscribed reliability class
In network to MS direction:
0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 1 Unused. If received, it shall be interpreted as '010' (Note)
0 1 0 Unacknowledged GTP; Acknowledged LLC and RLC, Protected data
0 1 1 Unacknowledged GTP and LLC; Acknowledged RLC, Protected data
1 0 0 Unacknowledged GTP, LLC, and RLC, Protected data
1 0 1 Unacknowledged GTP, LLC, and RLC, Unprotected data
1 1 1 Reserved
All other values are interpreted as Unacknowledged GTP and LLC; Acknowledged RLC, Protected data in this version of the protocol.
NOTE: this value was allocated in earlier versions of the protocol.
Delay class, octet 3 (see 3GPP TS 22.060 and 3GPP TS 23.107)
Bits
6 5
I
0 0 0 Subscribed delay class
In network to MS direction:
0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 1 Delay class 1
0 1 0 Delay class 2
0 1 1 Delay class 3
1 0 0 Delay class 4 (best effort)
1 1 1 Reserved
All other values are interpreted as Delay class 4 (best effort) in this version of the protocol.
Bit 7 and 8 of octet 3 are spare and shall be coded all 0.
Precedence class, octet 4 (see 3GPP TS 23.107)
Bits
3 2
I
0 0 0 Subscribed precedence
In network to MS direction:
0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 1 High priority
0 1 0
0 1 1 Low priority
1 1 1 Reserved
All other values are interpreted as
Bit 4 of octet 4 is spare and shall be coded as 0.
Peak throughput, octet 4 (see 3GPP TS 23.107)
This field is the binary representation of the Peak Throughput Class (1 to 9). The corresponding peak throughput to each peak throughput class is indicated.
Bits
8 7 6
I
0 0 0 0 Subscribed peak throughput
In network to MS direction:
0 0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 0 1 Up to 1 000 octet/s
0 0 1 0 Up to 2 000 octet/s
0 0 1 1 Up to 4 000 octet/s
0 1 0 0 Up to 8 000 octet/s
0 1 0 1 Up to 16 000 octet/s
0 1 1 0 Up to 32 000 octet/s
0 1 1 1 Up to 64 000 octet/s
1 0 0 0 Up to 128 000 octet/s
1 0 0 1 Up to 256 000 octet/s
1 1 1 1 Reserved
All other values are interpreted as Up to 1 000 octet/s in this
version of the protocol.
Mean throughput, octet 5 (see 3GPP TS 23.107)
This field is the binary representation of the Mean Throughput Class (1 to 18; mean throughput class 30 is reserved and 31 is best effort). The corresponding mean throughput to each mean throughput class is indicated.
Bits
5 4 3 2
I
0 0 0 0 0 Subscribed mean throughput
In network to MS direction:
0 0 0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 0 0 1 100 octet/h
0 0 0 1 0 200 octet/h
0 0 0 1 1 500 octet/h
0 0 1 0 0 1 000 octet/h
0 0 1 0 1 2 000 octet/h
0 0 1 1 0 5 000 octet/h
0 0 1 1 1 10 000 octet/h
0 1 0 0 0 20 000 octet/h
0 1 0 0 1 50 000 octet/h
0 1 0 1 0 100 000 octet/h
0 1 0 1 1 200 000 octet/h
0 1 1 0 0 500 000 octet/h
0 1 1 0 1 1 000 000 octet/h
0 1 1 1 0 2 000 000 octet/h
0 1 1 1 1 5 000 000 octet/h
1 0 0 0 0 10 000 000 octet/h
1 0 0 0 1 20 000 000 octet/h
1 0 0 1 0 50 000 000 octet/h
1 1 1 1 0 Reserved
1 1 1 1 1 Best effort
The value Best effort indicates that throughput shall be made available to the MS on a per need and availability basis.
All other values are interpreted as Best effort in this
version of the protocol.
Bits 8 to 6 of octet 5 are spare and shall be coded all 0.
Delivery of erroneous SDUs, octet 6 (see 3GPP TS 23.107)
Bits
3 2
I
0 0 0 Subscribed delivery of erroneous SDUs
In network to MS direction:
0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 1 No detect ('-')
0 1 0 Erroneous SDUs are delivered ('yes')
0 1 1 Erroneous SDUs are not delivered ('no')
1 1 1 Reserved
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol.
The MS shall consider all other values as reserved.
Delivery order, octet 6 (see 3GPP TS 23.107)
Bits
5 4
I
0 0 Subscribed delivery order
In network to MS direction:
0 0 Reserved
In MS to network direction and in network to MS direction:
0 1 With delivery order ('yes')
1 0 Without delivery order ('no')
1 1 Reserved
Traffic class, octet 6 (see 3GPP TS 23.107)
Bits
8 7
I
0 0 0 Subscribed traffic class
In network to MS direction:
0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 1 Conversational class
0 1 0 Streaming class
0 1 1 Interactive class
1 0 0 Background class
1 1 1 Reserved
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol.
The MS shall consider all other values as reserved.
Maximum SDU size, octet 7 (see 3GPP TS 23.107)
In MS to network direction:
0 0 0 0 0 0 0 0 Subscribed maximum SDU size
1 1 1 1 1 1 1 1 Reserved
In network to MS direction:
0 0 0 0 0 0 0 0 Reserved
1 1 1 1 1 1 1 1 Reserved
In MS to network direction and in network to MS direction:
For values in the range 00000001 to 10010110 the Maximum SDU size value is binary coded in 8 bits, using a granularity of 10 octets, giving a range of values from 10 octets to 1500 octets.
Values above 10010110 are as below:
1 0 0 1 0 1 1 1 1502 octets
1 0 0 1 1 0 0 0 1510 octets
1 0 0 1 1 0 0 1 1520 octets
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol.
The MS shall consider all other values as reserved.
Maximum bit rate for uplink, octet 8
Bits
8 7 6 5 4 3 2
I
0 0 0 0 0 0 0 0 Subscribed maximum bit rate for uplink
In network to MS direction:
0 0 0 0 0 0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 0 0 0 0 0 1 The maximum bit rate is binary coded in 8 bits, using a granularity of 1 kbps
0 0 1 1 1 1 1 1 giving a range of values from 1 kbps to 63 kbps in 1 kbps increments.
0 1 0 0 0 0 0 0 The maximum bit rate is 64 kbps + ((the binary coded value in 8 bits –01000000) * 8 kbps)
0 1 1 1 1 1 1 1 giving a range of values from 64 kbps to 568 kbps in 8 kbps increments.
1 0 0 0 0 0 0 0 The maximum bit rate is 576 kbps + ((the binary coded value in 8 bits –10000000) * 64 kbps)
1 1 1 1 1 1 1 0 giving a range of values from 576 kbps to 8640 kbps in 64 kbps increments.
1 1 1 1 1 1 1 1 0kbps
If the sending entity wants to indicate a Maximum bit rate for uplink higher than 8640 kbps, it shall set octet 8 to ”
Maximum bit rate for downlink, octet 9 (see 3GPP TS 23.107)
Coding is identical to that of Maximum bit rate for uplink.
If the sending entity wants to indicate a Maximum bit rate for downlink higher than 8640 kbps, it shall set octet 9 to ”
In this version of the protocol, for messages specified in the present document, the sending entity shall not request 0 kbps for both the Maximum bitrate for downlink and the Maximum bitrate for uplink at the same time. Any entity receiving a request for 0 kbps in both the Maximum bitrate for downlink and the Maximum bitrate for uplink shall consider that as a syntactical error (see clause 8).
Residual Bit Error Rate (BER), octet 10 (see 3GPP TS 23.107)
Bits
8 7 6
0 0 0 0 Subscribed residual BER
In network to MS direction:
0 0 0 0 Reserved
In MS to network direction and in network to MS direction:
The Residual BER value consists of 4 bits. The range is from 5*10-2 to 6*10-8.
0 0 0 1 5*10-2
0 0 1 0 1*10-2
0 0 1 1 5*10-3
0 1 0 0 4*10-3
0 1 0 1 1*10-3
0 1 1 0 1*10-4
0 1 1 1 1*10-5
1 0 0 0 1*10-6
1 0 0 1 6*10-8
1 1 1 1 Reserved
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.
The MS shall consider all other values as reserved.
SDU error ratio, octet 10 (see 3GPP TS 23.107)
Bits
4 3 2
I
0 0 0 0 Subscribed SDU error ratio
In network to MS direction:
0 0 0 0 Reserved
In MS to network direction and in network to MS direction:
The SDU error ratio value consists of 4 bits. The range is is from 1*10-1 to 1*10-6.
0 0 0 1 1*10-2
0 0 1 0 7*10-3
0 0 1 1 1*10-3
0 1 0 0 1*10-4
0 1 0 1 1*10-5
0 1 1 0 1*10-6
0 1 1 1 1*10-1
1 1 1 1 Reserved
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.
The MS shall consider all other values as reserved.
Traffic handling priority, octet 11 (see 3GPP TS 23.107)
Bits
2
I
0 0 Subscribed traffic handling priority
In network to MS direction:
0 0 Reserved
In MS to network direction and in network to MS direction: (for Interactive class)
0 1 Priority level 1
1 0 Priority level 2
1 1 Priority level 3
The Traffic handling priority value is ignored if the Traffic Class is Conversational class, Streaming class or Background class.
Transfer delay, octet 11 (See 3GPP TS 23.107)
Bits
8 7 6 5 4
I
0 0 0 0 0 0 Subscribed transfer delay
In network to MS direction:
0 0 0 0 0 0 Reserved
In MS to network direction and in network to MS direction:
0 0 0 0 0 1 The Transfer delay is binary coded in 6 bits, using a granularity of 10 ms
0 0 1 1 1 1 giving a range of values from 10 ms to 150 ms in 10 ms increments
0 1 0 0 0 0 The transfer delay is 200 ms + ((the binary coded value in 6 bits – 010000) * 50 ms)
0 1 1 1 1 1 giving a range of values from 200 ms to 950 ms in 50ms increments
1 0 0 0 0 0 The transfer delay is 1000 ms + ((the binary coded value in 6 bits – 100000) * 100 ms)
1 1 1 1 1 0 giving a range of values from 1000 ms to 4000 ms in 100ms increments
1 1 1 1 1 1 Reserved
The Transfer delay value is ignored if the Traffic Class is Interactive class or Background class.
Guaranteed bit rate for uplink, octet 12 (See 3GPP TS 23.107)
Coding is identical to that of Maximum bit rate for uplink.
If the sending entity wants to indicate a Guaranteed bit rate for uplink higher than 8640 kbps, it shall set octet 12 to ”
The Guaranteed bit rate for uplink value is ignored if the Traffic Class is Interactive class or Background class, or Maximum bit rate for uplink is set to 0 kbps.
Guaranteed bit rate for downlink, octet 13(See 3GPP TS 23.107)
Coding is identical to that of Maximum bit rate for uplink.
If the sending entity wants to indicate a Guaranteed bit rate for downlink higher than 8640 kbps, it shall set octet 13 to ”
The Guaranteed bit rate for downlink value is ignored if the Traffic Class is Interactive class or Background class, or Maximum bit rate for downlink is set to 0 kbps.
Source Statistics Descriptor, octet 14 (see 3GPP TS 23.107)
Bits
4 3 2
I
0 0 0 0 unknown
0 0 0 1 speech
The network shall consider all other values as unknown.
In network to MS direction
Bits 4 to 1 of octet 14 are spare and shall be coded all 0.
The Source Statistics Descriptor value is ignored if the Traffic Class is Interactive class or Background class.
Signalling Indication, octet 14 (see 3GPP TS 23.107)
Bit
5
In MS to network direction and in network to MS direction:
0 Not optimised for signalling traffic
1 Optimised for signalling traffic
If set to '1' the QoS of the PDP context is optimised for signalling
The Signalling Indication value is ignored if the Traffic Class is Conversational class, Streaming class or Background class.
Bits 8 to 6 of octet 14 are spare and shall be coded all 0.
Maximum bit rate for downlink (extended), octet 15
Bits
8 7 6 5 4 3 2
I
0 0 0 0 0 0 0 0 Use the value indicated by the Maximum bit rate for downlink in octet 9.
For all other values: Ignore the value indicated by the Maximum bit rate for downlink in octet 9
and use the following value:
0 0 0 0 0 0 0 1 The maximum bit rate is 8600 kbps + ((the binary coded value in 8 bits) * 100 kbps),
0 1 0 0 1 0 1 0 giving a range of values from 8700 kbps to 16000 kbps in 100 kbps increments.
0 1 0 0 1 0 1 1 The maximum bit rate is 16 Mbps + ((the binary coded value in 8 bits - 01001010) * 1 Mbps),
1 0 1 1 1 0 1 0 giving a range of values from 17 Mbps to 128 Mbps in 1 Mbps increments.
1 0 1 1 1 0 1 1 The maximum bit rate is 128 Mbps + ((the binary coded value in 8 bits - 10111010) * 2 Mbps),
1 1 1 1 1 0 1 0 giving a range of values from 130 Mbps to 256 Mbps in 2 Mbps increments.
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.
Guaranteed bit rate for downlink (extended), octet 16
Bits
8 7 6 5 4 3 2
I
0 0 0 0 0 0 0 0 Use the value indicated by the Guaranteed bit rate for downlink in octet 13.
For all other values: Ignore the value indicated by the Guaranteed bit rate for downlink in octet 9
and use the following value:
0 0 0 0 0 0 0 1 The guaranteed bit rate is 8600 kbps + ((the binary coded value in 8 bits) * 100 kbps),
0 1 0 0 1 0 1 0 giving a range of values from 8700 kbps to 16000 kbps in 100 kbps increments.
0 1 0 0 1 0 1 1 The guaranteed bit rate is 16 Mbps + ((the binary coded value in 8 bits - 01001010) * 1 Mbps),
1 0 1 1 1 0 1 0 giving a range of values from 17 Mbps to 128 Mbps in 1 Mbps increments.
1 0 1 1 1 0 1 1 The guaranteed bit rate is 128 Mbps + ((the binary coded value in 8 bits - 10111010) * 2 Mbps),
1 1 1 1 1 0 1 0 giving a range of values from 130 Mbps to 256 Mbps in 2 Mbps increments.
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.
Maximum bit rate for uplink (extended), octet 17
This field is an extension of the Maximum bit rate for uplink in octet 8. The coding is identical to that of the Maximum bit rate for downlink (extended).
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.
Guaranteed bit rate for uplink (extended), octet 18
This field is an extension of the Guaranteed bit rate for uplink in octet 12. The coding is identical to that of the Guaranteed bit rate for downlink (extended).
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.
沒有留言:
張貼留言