# AVPs DIAMETER, tipos de dados e Result-Code

> Os AVPs (Attribute-Value Pairs) transportam todos os dados DIAMETER. Cada um tem um AVP Code, um octeto de flags (V vendor, M mandatory, P reservado), um comprimento, um Vendor-Id opcional e um valor tipado. Os valores usam tipos base como Unsigned32, OctetString, Address, Time, Enumerated e Grouped. Os AVPs Result-Code e Experimental-Result reportam resultados.

- URL canônico: https://www.broadnet.me/pt/reference/diameter-avps-and-message-format
- Idioma: pt
- Última atualização: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

A anatomia de um AVP DIAMETER: código, flags V/M/P, comprimento, Vendor-Id opcional e dados; os tipos de dados base (Enumerated, Unsigned32, OctetString, Address, Time); os Grouped AVPs; e o modelo de erros Result-Code / Experimental-Result.

## Estrutura do AVP

Cada elemento de dados DIAMETER — identidades, campos de subscrição, quotas, resultados — é codificado como um AVP. Um AVP começa com um AVP Code de 32 bits, depois um octeto de flags, um comprimento de 24 bits que cobre todo o AVP, um Vendor-Id opcional de 32 bits, e o valor preenchido até uma fronteira de 4 octetos. O AVP Code sozinho é único dentro do espaço gerido pela IETF; quando a flag V (Vendor-Specific) está definida, o código é interpretado dentro do espaço de numeração do Vendor-Id que se segue — é assim que o 3GPP (Vendor-Id 10415) define as centenas de AVPs usados por S6a, Gx e Cx sem colidir com o protocolo base.

*Formato de AVP da RFC 6733*

```text
0                   1                   2                   3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         AVP Code (32)                      |
| V M P r r r r r|                AVP Length (24)            |
|              Vendor-Id (32)  — present only if V=1          |
|    Data ...  (padded to a 4-octet boundary)                |
```

## As flags V, M e P

Três flags de AVP governam como um recetor deve tratar o AVP. V (Vendor-Specific) assinala que se segue um Vendor-Id e que o AVP Code vive no espaço desse vendor. M (Mandatory) é a mais importante: se M estiver definida e o recetor não compreender o AVP, deve rejeitar toda a mensagem com DIAMETER_AVP_UNSUPPORTED (5001) — pelo que definir M erradamente quebra o interworking, e os AVPs de vendor que uma implementação pode ignorar em segurança são enviados com M apagada. P foi originalmente um marcador de segurança end-to-end; a RFC 6733 desaconselhou esse uso e o bit está agora reservado e definido a zero.

*Bits de flag do AVP*

| Flag | Nome | Significado quando definido |
|---|---|---|
| V | Vendor-Specific | Existe um campo Vendor-Id; o código está no espaço desse vendor |
| M | Obrigatório | O destinatário deve entender ou rejeitar a mensagem (5001) |
| P | (reservado) | Anteriormente segurança de ponta a ponta; obsoleta pela RFC 6733, definida como 0 |

## Tipos de dados base

Os valores de AVP são fortemente tipados. A RFC 6733 define um conjunto de tipos básicos e vários tipos derivados construídos a partir de OctetString. Os tipos integer e unsigned transportam contadores, identificadores e enumerações; OctetString transporta binário opaco ou estruturado; e os tipos derivados acrescentam semântica que uma implementação pode validar. Address codifica um endereço IP com uma família de endereço de dois octetos à frente. Time é uma contagem de segundos de 32 bits ao estilo NTP. Enumerated é um Integer32 cujos valores são nomeados pela aplicação. DiameterIdentity e DiameterURI transportam FQDNs e URIs de pares.

*Tipos de dados de AVP DIAMETER comuns*

| Tipo | Codificação | Uso típico |
|---|---|---|
| Unsigned32 / Integer32 | Inteiro de 32 bits | Contadores, quotas, Auth-Application-Id, Result-Code |
| Unsigned64 / Integer64 | Inteiro de 64 bits | Volumes em octetos, contadores grandes |
| OctetString | Octetos opacos | Payloads binários (vetores de autenticação, TPDUs) |
| UTF8String | OctetString | Texto legível por humanos (User-Name, nome do produto) |
| Enumerated | Integer32 | Conjuntos de valores nomeados (ex: RAT-Type, CC-Request-Type) |
| Address | OctetString + família | Endereços IPv4/IPv6 (Host-IP-Address, Framed-IP) |
| Hora | Unsigned32 | Segundos desde 1900 (Event-Timestamp) |
| DiameterIdentity | OctetString | FQDN do par (Origin-Host, Destination-Host) |
| Grouped | AVPs aninhados | AVPs que contêm outros AVPs |

## Grouped AVPs

Um Grouped AVP tem, como o seu valor, uma lista concatenada de outros AVPs — pelo que registos estruturados aninham-se de forma limpa sem novas regras de fio. Subscription-Data em S6a, Charging-Rule-Install em Gx e Experimental-Result transportam todos sub-AVPs dentro de um grupo. O agrupamento é recursivo: um Grouped AVP pode conter mais Grouped AVPs, o que é como um perfil de subscrição LTE completo ou um conjunto de regras PCC é expresso como um único AVP de topo. Cada AVP contido mantém o seu próprio código, flags e comprimento, pelo que um recetor analisa o grupo com a mesma maquinaria que usa no nível de topo.

## Result-Code e Experimental-Result

O DIAMETER reporta o resultado de um request na answer. O AVP base Result-Code (código 268) é um Unsigned32 agrupado em intervalos pelo dígito inicial: 1xxx informativo, 2xxx sucesso, 3xxx erros de protocolo (de um proxy/relay), 4xxx falhas transitórias que o cliente pode repetir, e 5xxx falhas permanentes. Quando uma aplicação precisa de um erro específico de vendor que o Result-Code base não consegue exprimir, usa o AVP Experimental-Result (código 297) — um Grouped AVP que transporta um Vendor-Id mais um Experimental-Result-Code — que é como o 3GPP sinaliza erros como DIAMETER_ERROR_USER_UNKNOWN ou DIAMETER_ERROR_ROAMING_NOT_ALLOWED.

*Intervalos de Result-Code e valores comuns*

| Intervalo | Classe | Exemplo |
|---|---|---|
| 1xxx | Informativo | 1001 DIAMETER_MULTI_ROUND_AUTH |
| 2xxx | Sucesso | 2001 DIAMETER_SUCCESS |
| 3xxx | Erro de protocolo (proxy) | 3002 UNABLE_TO_DELIVER, 3007 APPLICATION_UNSUPPORTED |
| 4xxx | Falha transitória (tentar novamente) | 4181 AUTHENTICATION_DATA_UNAVAILABLE (3GPP) |
| 5xxx | Falha permanente | 5001 AVP_UNSUPPORTED, 5012 UNABLE_TO_COMPLY |

## Perguntas frequentes

### O que é um AVP no DIAMETER?

Um AVP (Attribute-Value Pair) é a unidade de dados em cada mensagem DIAMETER. Transporta um AVP Code, um octeto de flags (V, M, P), um comprimento, um Vendor-Id opcional e um valor tipado. Todas as identidades, campos de subscrição, quotas e resultados são codificados como AVPs, e uma mensagem é um cabeçalho seguido por uma lista deles.

### O que faz a flag M (Mandatory)?

Se a flag M estiver definida e o recetor não compreender esse AVP, deve rejeitar toda a mensagem com DIAMETER_AVP_UNSUPPORTED (5001). Os AVPs que um par pode ignorar em segurança são, por isso, enviados com M apagada. O uso incorreto do bit M é uma causa comum de falhas de interworking entre vendors.

### O que é um Grouped AVP?

Um Grouped AVP é um AVP cujo valor é ele próprio uma lista de AVPs, permitindo que registos estruturados se aninhem. Subscription-Data, Charging-Rule-Install e Experimental-Result são Grouped AVPs. O agrupamento é recursivo, pelo que um perfil de subscrição LTE completo ou um conjunto de regras PCC pode ser transportado como um único AVP de topo.

### Como são identificados os AVPs específicos de vendor?

Pela flag V mais um campo Vendor-Id. Quando V está definida, um Vendor-Id de 32 bits segue-se ao comprimento e o AVP Code é interpretado dentro do espaço de numeração desse vendor. O 3GPP usa o Vendor-Id 10415 para definir os AVPs para S6a, Gx, Cx e as outras interfaces de aplicação.

### Qual é a diferença entre Result-Code e Experimental-Result?

O Result-Code (AVP 268) transporta os códigos de resultado base da IETF agrupados como 1xxx/2xxx/3xxx/4xxx/5xxx. O Experimental-Result (AVP 297) é um Grouped AVP com um Vendor-Id e um Experimental-Result-Code, usado quando uma aplicação precisa de um erro específico de vendor como o DIAMETER_ERROR_USER_UNKNOWN do 3GPP.

### O que significam os intervalos de result-code do DIAMETER?

1xxx é informativo, 2xxx é sucesso (2001 DIAMETER_SUCCESS), 3xxx é um erro de protocolo normalmente levantado por um proxy, 4xxx é uma falha transitória que o cliente pode repetir, e 5xxx é uma falha permanente. O dígito inicial diz ao cliente se deve repetir, falhar ou reencaminhar.

## Fontes

- [IETF RFC 6733 — Diameter Base Protocol (AVPs, section 4)](https://datatracker.ietf.org/doc/html/rfc6733)
- [3GPP TS 29.272 — S6a/S6d AVP definitions](https://www.3gpp.org/dynareport/29272.htm)

## Relacionados

- [Protocolo base DIAMETER (RFC 6733)](https://www.broadnet.me/pt/reference/diameter-base-protocol)
- [DIAMETER vs RADIUS](https://www.broadnet.me/pt/reference/diameter-vs-radius)
- [DIAMETER S6a/S6d para o HSS](https://www.broadnet.me/pt/reference/diameter-s6a-s6d-hss)
- [Política e tarifação DIAMETER Gx/Gy](https://www.broadnet.me/pt/reference/diameter-gx-gy-policy-charging)
- [Programadores](https://www.broadnet.me/pt/developers)