5G

Cisco Pune

5G Protocols

1
Modules 8: 5G Core Network Protocols

• HTTP

• PFCP

• NAS

• Diameter

• SIP

• RTP

2
HTTP

3
HTTP
• Use Case SBA
• Preferred Version : HTTP 2.0

4
HTTP Commands and stack
• Request

• Response

• Subscribe

• Notify

5
PFCP

6
Use case of PFCP Protocol
• Sxa - between SGW-C and SGW-U
• Sxb - between PGW-C and PGW-U
• Sxc - between TDF-C and TDF-U
• N4 - between SMF and UPF

7
Protocol Stack

8
PFCP Interfaces

9
PFCP Protocol in 5G

10
 SIP - Session Initiation Protocol
SIP
▪

▪ establishing of multimedia
sessions in IP networks

▪ SIP is a Peer-to-Peer Protocol

▪ SIP has a client/server

architecture

▪ transaction based (requests and

responses)

▪ IETF signaling protocol: RFC2543,

RFC3261

▪ SIP messages may carry different

contents (SDP, ISUP, E-Mail,
Picture)

11

The Session Initiation Protocol (SIP) is an application-layer signalling protocol

that can establish, modify and terminate multimedia sessions over IP
Protocol. SIP has been standardized by the IETF. In November 2000, SIP
was accepted as a 3GPP signalling protocol and permanent element of the
IMS architecture.

The SIP protocol is exchanged between terminals (SIP terminals) and the
network as well as between SIP servers within the network, so it is a user-
network and a network-network protocol.
SIP only opens and closes sessions for various applications; hence it is free
to work for any suitable service type whether old or new. This allows reusing
existing SIP architecture in various ways for new developments.
SIP is only the framework for session control; it can work with different styles
of session description (e.g. quality of service parameters, media descriptor
 1
2

SIP in IMS Network

Usage of SIP :
After UE finishes radio procedures and it establishes rad
The VoLTE UE initiates a SIP REGISTER to the P-CSCF, using the P-CSCF
IP Address that was made available during the LTE Attach io bearers UE can
start SIP registration towards the IMS for VoLTE call.

Company Confidential
 1
3

SIP message structure

The start-line in a request is named Request-Line, and the start-line in a

response is named Status-Line.
Any SIP message must contain header fields, whereas a message body is
optional, depending on the message type and service requirements.
Header fields and the message body are separated by a carriage-return line-
feed sequence (CRLF), which indicates the end of the header fields.
A message body can be a specific implementation mode of the current
session, which is described by using SDP or text.
BASIC SIP FLOW

1. INVITE

2. TRYING (100)

3.RINGING (180)

4. OK (200)

5. ACK

Media Stream (e.g. RTP)

6. BYE

7. OK (200)

14
 1
5

Standard SIP Requests

INVITE starts dialogue; initiates or modifies sessions

ACK acknowledges INVITE transactions

CANCEL aborts pending requests (especially INVITES)

BYE terminates activated sessions

REGISTER registers possible contact addresses for a user

OPTIONS used to query servers about their capabilities

INVITE:A request for initiating a session and inviting other parties to join the
session. The proposed description of the session is carried in the message
body. For a two-party call, the calling party indicates the desired media types
and media parameters in the session description. The called party must
indicate the accepted media or media to be used in the message body of the
response.
ACK :An acknowledgement for the final response to the INVITE request. The
ACK request is used in conjunction with the INVITE request.
BYE:A request for terminating sessions.
CANCEL:A request for canceling a previous request sent by a client. CANCEL
does not affect a request to which a final response is received.
REGISTERA request for registering contact information.
OPTIONS: A request for querying servers about their capabilities.
 1
6

SIP Response codes

1xx Provisional Response server has no final response yet

2xx Successful Response request was processed with successful outcome

F
I 3xx Redirecting Response server delivers new server addresses that can
N fulfill the requested service
A
L
4xx Request Failure server was not able to process this request;
the client shall either modify the request or choose
R
E another server
S
P 5xx Server Internal Error server is not able to process this request;
O possibly this indicates only temporary failure
N
S 6xx Global Failure global error situation, such that service is not
E possible at all
S

SIP response is a message generated by a user agent server (UAS) or SIP server to reply a request
generated by a client. It could be a formal acknowledgement to prevent retransmission of requests by a
UAC.
A response may contain some additional header fields of info needed by a UAC.
SIP has six responses.
1xx to 5xx has been borrowed from HTTP and 6xx is introduced in SIP.
1xx is considered as a provisional response and the rest are final responses.

a)1xx: Provisional/Informational Responses

Informational responses are used to indicate call progress. Normally the responses are end to end
(except 100 Trying).

b) 2xx: Success Responses

This class of responses is meant for indicating that a request has been accepted.

c) 3xx: Redirect Responses

Generally these class responses are sent by redirect servers in response to INVITE. They are also
known as redirect class responses.

d) 4xx: Client Failure Responses

Client error responses indicate that the request cannot be fulfilled as some errors are identified from the
UAC side.

e) 5xx: Server Failure Response

This class response is used to indicate that the request cannot be processed because of an error with
the server.

f).6xx: Global Failure Response

This response class indicates that the server knows that the request will fail wherever it is tried. As a
result, the request should not be sent to other locations.

Company Confidential
SIP Response Codes 1xx-6xx
Response Code
100 (Trying)
180 (Ringing)
181 (Call Forwarded)
182 (Queued)
183 (Session Progress)
200 (OK)
300 (Multiple Choices)
301 (Moved Permanently)
302 (Moved Temporarily)
305 (Use Proxy)
380 (Alternative Service)
400 (Bad Request)
401 (Unauthorized)
402 (Payment Required)
403 (Forbidden)
404 (Not Found)
405 (Method Not Allowed)
406 (Not Acceptable)
407 (Proxy Authentication Req.)
408 (Request Timeout)
410 (Gone)
413 (Request Entity Too Large)
Meaning
server has received request and is now performing some unspecified action
invited user is alerted (used for local ringback)
server indicates that this call is now subject to call forwarding to another set of
destinations
called party is temporarily unavailable, but server queued call instead rejecting it
unspecified progress events of the call; (for instance used to indicate ISUP: ACM)
request is successfully completed.
originally specified address was resolved to multiple choices; user can now specify
one of these destinations and direct the session request to it
called user can no longer be found at the requested address; client should try new
address instead
client shall try one the alternative addresses (CONTACT header) for the user
the requested resource msut be accessed through the proxy given in CONTACT header
call was not successful, but alternatieve services are available
request could not be processed due to invalid syntax
request requires user authentication (used by user agent servers and registrars)
reserved for future use
server understands request, but refuses it; (authorization will not overcome the error)
server has definitive information that user does not exist at the domain specified in
the request (Request URI)
request method not allowed for the specified address (Request URI)
resource identified by the request is not capable of handling the specified content
characteristics
client must first authenticate itself (used by proxies)
server was not a ble to produce any other response within suitable amount of time
requested resource no longer available at server, no forwarding address known
request message body too large for this server
17
17
SIP Response Codes 1xx-6xx(Cont.)
Response Code
414 (Request URI Too Long)
415 (Unsupported Media Type)
416 (Unsupported URI Scheme)
420 (Bad Extension)
421 (Extension Required)
423 (Interval Too Brief)
480 (Temporarily Unavailable)
481 (Call/Transaction does not exist)
482 (Loop Detected)
483 (Too Many Hops)
484 (Address Incomplete)
485 (Ambi guous)
486 (Busy Here)
487 (Request Terminated)
488 (Not Acceptable Here)
491 (Request Pending)
493 (Undecipherable)
500 (Server Internal Error)
501 (Not Implemented)
502 (Bad Gateway)
503 (Service Unavailable)
504 (Server Time-Out)
505 (Version Not Supported)
513 (Message Too Large)
Meaning
request URI is longer than the server is willing to interpret
message body is of a format not supported by the server for this method
server cannot process request because URI scheme is unknown
server did not understand protocol extension in a REQUIRE or PROXY-REQUIRE
header
user agent server needs a particular extension to process the request, but this
extension is not listed in the SUPPORED HEADER field
expiration time of resource refreshed by the request is too short
called party's end system was contacted, but user unavalaible (e.g. not logged on)
Call-ID or tags wrong
server has detected a message loop
MAX-FORWARDS header field reached 0
request-URI was not sufficient to find an end system
request-URI was ambiguous (multiple called parties possible)
called party successfully contacted, but called pary not willing or able to take
another call
the request was terminated by BYE or CANCEL request
the wanted request is not possible at the specified address
in the same dialogue is a already a request pending
encrypted message body was not decipherable
server encountered unexpected condition making any processing of the request
impossible
the requested service is not available at this server
server received a bad request from next server
server is temporarily unable to process the request (overload or maintenance)
sever did not receive response from an external server in time
server does not support the used SI P version
server was unable to process request becuase of excessive message length
18
18
SIP Response Codes 1xx-6xx(Cont.)
Response Code Meaning

600 (Busy Everywhere) called party does not wish to take cal at this time

603 (Decline) called party does not want to participate in session

604 server has authoritative information that the user

(Does Not Exist Anywhere) (Request-URI) does not exist anywhere

606 (Not Acceptable) user agent of called party was contacted successfully,
but session description, bandwidth or addressing style are
not acceptable

19

19
 2
0

SDP Message structure example

Each SDP parameter is described by type identifier that is a case-sensitive

character (only one character). For instance 'v' is standing for the version
parameter.
After the type indication follows an equality sign and then the parameter
value. The value can be composed of several sub-values separated by a
blank space.
Several of these <type>=<value> lines, each ending with a CRLF, form the
SDP description for a session.

The description itself contains

session description,
time description and
media description.

Company Confidential
NAS

21
DIAMETER

22
Use case
• R5 protocol
• PCF – P-CSCF

23
 2
4

Diameter – Client /Server Protocol

Relay/Proxy/Server

connection A connection B

client server
session
• Authorization
• Authentication
• Accounting

Diameter is an Authentication, Authorization, and Accounting (AAA) protocol initially

developed by the Internet Engineering Task Force (IETF) for applications such as
network access and IP mobility. This protocol is an alternative or upgrade to Remote
Authentication Dial In User Service (RADIUS), because it has overcome RADIUS
limitations in security.

The Diameter protocol consists of the Diameter base protocol and various Diameter
applications.
The Diameter base protocol defines Diameter entities and specifies common
functionalities, including Diameter message delivery, capability negotiation between
Diameter nodes, and error handling.
Diameter applications extend the Diameter protocol by defining service-specific
commands and data units. Examples of Diameter applications include Network
Access Server (NAS), Extensible Authentication Protocol (EAP), Mobile IP (MIP),
and Cryptographic Message Syntax (CMS).
Diameter is a peer-to-peer protocol. Either Diameter node of a link can initiate a
request. If two Diameter links have been established between two nodes, one link is
disabled according to an election mechanism.
In the Diameter protocol, IDs are defined for applications and are included in
Diameter message headers to identify the layers from which messages are sent.
Diameter messages are exchanged in request-answer mode. A Diameter message
consists of a header field and AVPs. A diameter header carries the version, message
length, command flag, command code, application ID, hop-by-hop identifier, and
end-to-end identifier. AVPs encapsulate information related to the Diameter message
and can be added by carriers

Company Confidential
 2
5

Diameter Protocol Stack

The Diameter base protocol runs over TCP or SCTP. TCP establishes an
independent connection for each stream, while SCTP bundles several independent
streams into a single SCTP association.
Transport Level Security (TLS) provides security for transport connections, and IP
Security (IPSec) provides security for hop-to-hop connections. Diameter clients must
support either TLS or IPSec. Diameter servers must support both TLS and IPSec.
Diameter cannot run without TLS or IPSec.

DIAMETER base protocol: The DIAMETER base provides the very basic
communication framework with messages and root parameter formats. It does not
contain any specific application message. The DIAMETER base protocol uses TCP
or SCTP for transmission of messages.
DIAMETER Application: The DIAMETER application is placed on top of the base
protocol to use the offered communication facilities. The DIAMETER application itself
provides new request/response messages specific for the services to be provided by
the application. Associated with this are parameters derived from the basic
parameter formats used for the application specific behavior.

Each Diameter application must have Application Identifier, assigned by IANA. The
base protocol does not require an Application Identifier since its support is
mandatory. During the capabilities exchange, Diameter nodes inform their peers of
supported Application. Furthermore, all Diameter messages contain an Application
Identifier. In this context, a Diameter Application means a protocol.

Company Confidential
 2
6

Diameter – Message structure(1/1)

The communication between 2 Diameter Agents is done via message-

exchange. Messages are always in pairs, one is a Command Code Request
(from Client to Server), and the next is an Answer.
All DIAMETER messages follow a basic layout. It consists of the a Header (20
octets long), called the Diameter Header, followed by a changeable number
of AVPs. This message structure is the same in all Diameter applications.
 2
7

Diameter –Message structure(1/2)

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1

Version
Message Length
Command Flags Command Code

Application ID

Hop-by-Hop Identifier

End-to-End Identifier

AVPs

R P E T r r r r
R(equest) 1=Message is Request; 0=Message is Answer
P(roxiable) 1=Message may be proxied; 0=Message must be locally processed
E(rror) 1=Message contains a protocol error (only for answer messages)
T 1=Indicates, that this message is potentially a retransmission

Version
The version field describes the DIAMETER base protocol version used. For the present
document this version must be set to 0x01 (version 1).
Message Length
Length of DIAMETER message including header fields in octets.
Command Flags
This field contains three bits. First the R-bit is used to indicate whether the message is a
request (1) or a response (0). The P-bit indicates whether the message may be proxied (1) or
must be handled locally (0). The last bit is the E-bit which is only for responses important. If
E=1 then the response contains an error.
Command Code
The command code contains the procedure indicator the message belongs to.
Application ID
The application identifier indicates which DIAMETER application is sending/receiving the
message.
Hop-by-Hop ID
This identifier has significance per connection. It is used to associate responses to requests.
End-to-End ID
This is an identifier for the message which remains the same for all connections the message
is sent on. It might be used to detect duplicated messages. This identifier must be unique for a
time period of at least 4 minutes.

The Header is followed by one or more Attribute-Value-Pairs (AVPs). An AVP is used to

encapsulate protocol-specific data. It is possible, for a new application, to create a new AVP
or define a new AVP value. Of course, new applications should attempt to reuse AVPs
defined in existing applications always when possible.
RTP

28
 2
9

RTP/RTCP Functions
- quality measurements
- identification of session parties

quality: number of lost packets

interarrival jitter
Application delay

- Data Transfer - quality feedback reports

- Source Identification RTP RTCP - transport level identification
- Time Stamps of SSRC

UDP

IP v6

Layer 2 / Layer 1

The most critical problem for real time applications in an IP environment is to

guarantee a minimum level of quality of service. Neither RTP nor RTCP can
provide that, but RTCP can transport measurement reports about the current
quality available from the network.
Basically three major points can be used to describe the current quality:
number of lost RTP packets,
inter-arrival jitter,
overall delay.

These three things can easily be measured by every RTP stream end-point.
The sequence number and the time stamp in the RTP header are used for
this purpose. These measurements can be exchange by the end-points using
RTCP protocol messages. Furthermore if synchronization entities are used
their Synchronization Source Identifiers are exchanged with the RTCP
protocol at session begin.
 3
0

RTP Payload types

Payload Type encoding name Audio/Video clock rate channels

0 PCMU A 8000 1

2 G.721 A 8000 1

3 GSM (FR) A 8000 1

9 G.722 A 8000 1

15 G.728 A 8000 1

26 JPEG V 90,000 n.a.

31 H.261 V 90,000 n.a.

96 - 127 dynamic dynamic dynamic dynamic

When using RTP it is always necessary to have an accompanying specification

defining the format of the real time data to be transported.

Some of these formats are already defined by IETF as there are:

PCMU
This indicates uniform PCM. So it describes the format of classical audio sampling
with equidistant intervals. The sampling rate is 8 kHz with a sampling width of 8 bits
per sample..
G.721/722/728
These are different ITU-T audio codecs. Especially G.722 and G.728 are designed
by transport over packet networks. All three codecs are running with 8 kHz sampling
rate, but they differ essentially in their coding.
GSM (FR)
This is the standard GSM full rate speech codec. It produces 244 bit long codec
frames every 20 ms. Thus it requires a data rate of around 12 kbps. Also the FR
codec works with a sampling rate with 8 kHz (and 13 bits per sample), but this
indication is principle useless here.
JPEG
The JPEG picture expert group has not only specified JPEG as picture compression
format, but also for video compression. JPEG therefore describes a video format.
H.261
H.261 is the standard video/audio format defined by ITU-T used for video-telephony.
It is already old-fashioned and will be substituted by H.264 and MPEG4.
 3
1

RTP session with RTCP and UDP port

number usage

UDP port 2n : RTP data stream

UDP port 2n+1 : RTCP control

Endpoint A Endpoint B
IP Address A IP Address B

In contrast to IP applications like HTTP, FTP, etc. RTP does not have a well
defined port number assigned.
It is up to a session controlling protocol like SIP and a bearer control protocol
like MEGACO to communicate the UDP port numbers for a RTP stream
belonging to an application. This mechanism of course allows to have multiple
RTP streams terminated at the same host.
RTP uses always even numbered port numbers. If RTCP is used in
conjunction with RTP it must use the next higher (odd) port number.
H.248

32
 3
3

H.248 Protocol Stack

The H.248 protocol is a media gateway control protocol and applies to

interfaces between the media gateway controller (MGC) and multimedia
gateway (MGW) on the IMS network. For example, the protocol applies to the
following interfaces: Mp interface between the multimedia resource function
controller (MRFC) and multimedia resource function processor (MRFP), and
the Ix interface between the interconnection border control function (I-BCF)
and MRFP. The MRFC and I-BCF are MGCs, and the MRFP is an MGW. The
MGC controls the MGW through the H.248 protocol. Therefore, the MGW
performs specific functions, including bearer connection establishment and
media flow management.
 3
4

MGC
the management of resources
on the MG

3GPP defined:
Media Mn Interface: MGC <> IM MGW
(3GPP TS 29332)
Controller Iq Interface: P-CSCF <> IMS A-BGW
(3GPP TS 29.334)
Ix Interface: IBCF <> TrGW
H248 / (3GPP TS 29.238)
MEGACO Mp Interface MRFC- MRFP

MGW
media media

MG
connection point between
two dissimilar networks

H.248 is used between Media Gateway (MGW) and Media Gateway Controller (MGC: e.g. MSC Server).
The protocol has the following main tasks:
control bearer connection setup, modification and release;
indication of events concerning the bearer connections;
trigger and detection of tones and signals on the bearer;
retrieval of statistics about the bearer connection.

Call bearer control protocols are usually specific to the transport technology used, but are also dependent on the
system (e.g. UMTS).
ITU-T defined a basic framework for CBC protocols based on the standard H.248. The same framework is also
provided by IETF for IP environments. In IETF, H.248 is called Media Gateway Control (MEGACO) protocol.

H.248 provides a generalized model how to perform bearer connection control between network control plane and
transport network plane. Four a CBC is needed:
Framework: A framework specifies the functional architecture, interfaces and abstract models.
Messages: Messages are the basic communication units exchanged between functional units defined in the
framework.
Parameters, Events and Signals: Events describe what is detectable and reportable. Signals are various indications
running on the bearer (e.g. busy tone). Parameters describe how bearers and related things can be described.
Procedures: Procedures define rules and actions associated with messages, parameters, signals and events.

A PSTN/CS gateway interfaces with PSTN circuit switched (CS) networks. For signalling, CS networks use ISDN
User Part (ISUP) (or BICC) over Message Transfer Part (MTP), while IMS uses SIP over IP. For media, CS
networks use Pulse-code modulation (PCM), while IMS uses Real-time Transport Protocol (RTP).

A signalling gateway (SGW) interfaces with the signalling plane of the CS. It transforms lower layer protocols as
Stream Control Transmission Protocol (SCTP, an IP protocol) into Message Transfer Part (MTP, an Signalling
System 7 (SS7) protocol), to pass ISDN User Part (ISUP) from the MGCF to the CS network.
A media gateway controller function (MGCF) is a SIP endpoint that does call control protocol conversion between
SIP and ISUP/BICC and interfaces with the SGW over SCTP. It also controls the resources in a Media Gateway
(MGW) across an H.248 interface.
A media gateway (MGW) interfaces with the media plane of the CS network, by converting between RTP and PCM.
It can also transcode when the codecs don't match (e.g., IMS might use AMR, PSTN might use G.711)

34