IMS Overview

IMS (IP Multimedia Subsystem) has been described from 3GPP Rel-5. Since lots of LTE carriers even including 3GPP2 related ones have been heading for IMS deployment, several similar terms/concepts confuses us for a while. I can break down what IMS related terms e.g. SIP, VoIP, VoLTE, and etc. mean and compare confusing terms below.

The above picture shows us the related terms and indicates difference between VoIP and VoLTE simply. Before understanding what IMS is, personally I recommend to learn how SIP works in protocol perspective.

SIP (Session Initiation Protocol)

SIP is a signalling protocol, widely used for controlling multimedia communication sessions such as voice and video calls over IP networks. It works in conjunction with several applications layer protocols to do services. Media identification and negotiation is achieved with SDP (Session Description Protocol) and transmission of media streams employs RTP (Real-time Transport Protocol).

SIP network defines several network elements such as User Agent, Proxy server, Registrar, Redirect server, and Gateway to PSTN (Public Switched Telephone network). And SIP has been developed and standardized in RFC3261 under IETF.

IMS (IP Multimedia Subsystem)

IMS is an architecture framework under IP multimedia services. IMS uses IETF protocols and one of typical protocols is SIP. This is not intended to work as application servers, but to inter-work from wireless/wireline terminals through access networks to application servers in service layer.

Access networks can be variable depending on what kinds of terminals are used and it could be mobile/cellular access (e.g. LTE, UMTS), wireless access (e.g. WLAN), fixed access (e.g. DSL). Other phone systems like PSTN (Public Switched Telephone network) and non IMS-compatible VoIP system are supported through gateways. Application servers could be variable depending on services such as OIR (Originating ID Restriction)/TIR (Terminating ID Restriction), Supplementary Services, Conference, and etc.

The core component of IMS is CSCF (Call Session Control Function), which is divided into Proxy-CSCF, Serving-CSCF, and Interrogating-CSCF. It refers to HSS during authentication procedure and also uses gateways in order to interwork with non-IMS network.

VoIP (Voice over IP) vs. VoLTE (Voice over LTE)

The term VoIP covers any phone calls made over the Internet as opposed to traditional PSTN (Public Switched Telephone network). This service has been deployed with IP phone as well as various applications on PC e.g. Skype, Lync, Hangout.

Unlikely "naked" or "free" VoIP, the term VoLTE supplies subscribers with VoIP services over LTE mobile access network through IMS. SPS (Semi-Persistent Scheduling) for saving cellular network resource in VoLTE calls is used in LTE. And also in IMS, CSCF (Call Session Control Function)s and extra charging elements are required.

Difference between IMS and non-IMS services

First of all, since operators got involved in this and described in 3GPP specifications, more features are added on pure naked SIP network. IMS defines specific network components and CSCF (Call Session Control Function)s are most critical ones in there.Some of other network components are allowed to interwork with wireless core network. So QoS can be managed per user for various multimedia with charging and emergency calls can be handled. Based on my learning here is comparison chart below.

SIP Requests and Responses

Based on SIP specifications, there are bunch of Request Method in Request-Line and Response Codes in Response-Line. On the bottom of this post, I made up a list for Request Methods and Response Codes. And how to use the major request/response operation with examples in this post.

INVITE ( / 200 OK / ACK ) operation

When a user agent desires to initiate a session, it gets started with INVITE request. Unlike other requests, INVITE needs three-way handshake; INVITE / 200 OK / ACK. There is no separate ACK transaction, which means TU passes one directly to the transport layer for transmission and does not wait for response to it.

Other methods are expected to complete rapidly and non-INVITE transactions are known as two-way handshake. INVITE transaction is different from other methods because it takes some duration to receive the final response, 200 OK. Normally human input is required on the callee's end point system, 1xx provisional responses like 100 Trying, 180 Ringing and etc. can be used before the final response like 200 OK  is sent by the callee.

When the client receives 1xx responses, retransmission cease altogether and wait for the final response. If other responses like 3xx, 4xx, 5xx, or 6xx are received, the caller can retry INVITE.

On the above example, the caller initiates a call with INVITE and it alerts the callee's device and ring back tone can be hear on the caller side. When the callee answers the call, 200 OK final response is sent to the caller and ACK is sent from the caller as final message in this 3-way INVITE operation. And also Cseq (sequence number and method) in ACK is combined from INVITE as original request and ACK as another.

PRACK ( and UPDATE) operation

PRACK method is used by clients in order to ask callee's network to reserve network resource for call establishment. Supported header field with option tag "100rel" must be included in INVITE request and Require header field containing option tag "100rel" in non-100 responses to the request before doing PRACK related operation.

When PRACK operation is negotiated, UPDATE method can be used in order to update SDP description on both client and server sides. Depending on how to negotiate SDP features between the caller and callee, there are 2 different status types; End-to-End Status Type and Segmented Status Type.

- End-to-End Status Type: Reservation gets started on both sides for further SDP negotiation with UPDATE methods
- Segmented Status Type: Caller's resource reservation is done before INVITE request

Here is an example with PRACK operation for the first case. Supported with 100rel in INVITE request with SDP (a=curr:qos e2e none) is sent to the callee, then the callee's network resource reservation can get started with 183 Session Progress response. Since callee's reservation got started first and assure callee's sending resource is reserved, the callee asks confirmation of the caller's sending resource (a=conf:qos e2e recv). After the caller receive this, caller's sending resource reservation gets started under PRACK operation. When reservation is done, UPDATE request is sent with it's modified SDP (a=curr:qos e2e send). Lastly the callee sends 200 OK response with it's modified SDP (a=curr:qos e2e sendrecv), which meets the original destination status.

And here is another example for Segmented Status Type. In this case caller's network resource reservation can be started before INVITE is sent from the caller. Since the INVITE includes reserved resource related SDP (a=curr:qos local sendrecv, a=curr:qos remote none), the callee should reserve resource after the request received. Reservation is done and then 180 Ringing with modified SDP (a=curr:qos local sendrecv) is sent to the caller. Since SDP modification is completed, PRACK and other INVITE related operation is deployed without UPDATE operation.

Let's clarify each SDPs attributes for these 2 different types with comparison table below.

REGISTER operation

A user agent must place registration before make or receive calls through SIP protocol. In protocol message perspective, REGISTER operation is quite simple and usage of header fields is a bit different from other requests. Both To and From header fields have the same contents because REGISTER request does not have purpose to call another but register itself.

When REGISTER is shown in Wireshark log, it seems pretty much simple and 200 OK response says 1 bindings. In order to understand what this means, SIP message does not help and need to understand how server side works based on RFC 3261.

Here is another example, which I draw based on my understanding of Figure 2: REGISTER example in RFC 3261. When UA sends REGISTER request to Registrar server, To and Contact header fields are critical role on server side. Registrar asks Location server to add this user, domain name (address-of-record) in To header field and Contact address, which is so called, binding on Location server. These Registrar and Location servers could be located in the same or different position. This picture below shows logical operation how to handle REGISTER request through network. Once a UA is registered on a location server, another UA can refer to that Location server via proxy servers in order to call the first UA.

UAs can use 3 steps to determine the address to which to send a REGISTER request; 1) by configuration of phone side, 2) using the address-of-record, 3) multicast. If there is not configuration of registrar address on device side, UA should use the host part of the address-of-record in Request-URI.

Authorization/Authentication can be required while registration or call. Here is an example with REGISTER operation. UAC originates REGISTER request with Authorization field header, which does not have credentials; no nounce and response values. UAS can challenge the originator to provide credentials by rejecting it with a 401 Unauthorized status code. WWW-Authentication header field in the response contains authentication algorithm and parameters such as nounce, qop, and opaque. Once UAC receives this, the same request with more parameters in Authorization header field including generated response value. Finally 200 OK response comes out from UAS after add binding.

SUBSCRIBE / NOTIFY operation

UAs use SUBSCRIBE operation in order to refresh remote state, server's state when they would like to subscribe to resource or call state for various resources in the network. Server on network side sends notification when those stages changed.

SUBSCRIBE method includes Expires header with number and Event header with event package name. In registration procedure, Event header with "reg" tag is used in SUBSCRIBE request and the 200 OK response is sent. This SUBSCRIBE method uses a new Call-ID and a new tag, which are different from what used in previous dialog. If the Event header cannot be understood on server side, non-200 class responses like 489 Bad Event or 406 Not Acceptable are sent.

After resource is reserved and refresh state on network side, NOTIFY method is sent to the UA. This includes Event header with "reg" tag as well as Subscription-State header with state (active, pending, terminated, or so) and expires.

Lastly, here is the list for SIP Requests and Responses

SIP Structure and Header Fields

SIP protocol seems using pretty much simple terms but most terms are rolling up like a snowball, then it gets so confusing to us. Based on RFC3261, SIP protocol structure is defined, which does not belong to OSI defined layers.

SIP Protocol Structure

According to RFC3261 5 Structure of the Protocol, SIP protocol layers can be defined as follows; Syntax and Encoding, Transport layer, Transaction layer, Transaction user.


SIP - Syntax and Encoding

Encoding is specified using an augmented Backus-Naur Form grammar (BNF) as received from trasnport layer

SIP - Transport Layer

This layer defines how a client transport sends requests and receives responses and how a server is responsible for actual reception of requests and transmission of response over network. It is responsible for managing persistent connections for transport protocols like UDP and TCP over network. The opened connections are shared between the client and server transport functions. These connections are indexed by the tuple formed from address, port, transport protocol.

OSI layer also defines transport layer such as UDP, TCP, and etc., and then "port" term seems pretty much confusing here. What RFC3261 calls those UDP, TCP, and SCTP is "Transport protocol" and presents port on UDP, TCP, SCTP, or etc. "SIP - Transport layer" on top of "Transport protocol" also has a logical concept of "port"; source and receive ports. Since the source port on SIP protocol is often ephemeral, but it cannot be known whether is ephemeral or not on destination side, 2 different connections in use; one for requests and the other for responses.

SIP - Transaction Layer

This layer has a client and server side (client transaction and server transaction specifically called). Both client and server transactions are logical functions that are embedded in any number of elements. UAC, UAS, and stateful proxy have transaction layer have transaction layer and stateless proxy does not have transaction layer.

Client transaction sends requests and server transaction sends responses over network. Client transaction receives requests from TU (Transaction User) and delivers them to a server through network. Client transaction also receives responses and delivers them to the TU. Server transaction receives requests from transport layer and delivers them to the TU. Server transaction accepts responses from the TU and delivers them to transport layer over network.

SIP - Transaction User

Transaction User (TU) is SIP entities, which includes UAC core, UAS core, proxy core, and registrar core. There is no TU in stateless proxy. When a TU wishes to send a request, it creates a client transaction instance and passes the request along with destination info (destination IP address, port, and transport). When a client cancels a transaction, it requests that the server stop further processing, revert to the initial state. This is done with a CANCEL request.

In short, since Syntax and Encoding is a function, which does not have any state machine. If it is regardless, we can get clearer pictures below.

Even though SIP protocol layers are described in RFC3261, there are more terms still confusing as follows.

Message (with Method) and Message Body (with SDP)

Message is data sent between SIP elements as part of the protocol. SIP messages are either requests or responses. Method is primary function that a request mean to invoke on a server side for example, INVITE and BYE. SIP protocol transaction can be initiated by any requests first and appropriate responses are expected all the time.

SIP message contains Message Body if necessary and Session Description Protocol is one of most common bodies in there. It contains session name, purpose, media comprising the session, and bandwidth information and etc. Based on RFC specifications, SIP protocol sequence can be understood by SDP offer and answer.

SIP messages' direction refers to who sends requests while SDP session description does to who sends offers first. More detailed SDP headers are listed up on the bottom of this post.

Client and Server

Client is any network element which sends SIP requests and receives SIP responses. Clients typically may interact directly with a human user. User agent clients and proxies are clients. Server is any network element, which receives SIP requests in order to service them and sends back responses to those requests. Examples are proxies, user agent servers, redirect servers, and registrar.

(Back-to-Back) User Agent, UAC, and UAS

Back-to-Back user agent is logical entity. User agent receives a request and processes it as a user agent server (UAS) as well as it also acts as a user agent client (UAC) and generates a request.

Upstream and Downstream

A direction of request message from a client side to a server side is defined as downstream. We might think of client -> proxy -> proxy .. proxy -> proxy -> server. Unlike this, upstream is defined as a direction of responses flow from a server side to a client side. We can simply say server -> proxy -> proxy .. proxy -> proxy -> client.

Call, Dialog, and Session

Dialog means a peer-to-peer SIP relationship between 2 UAs that persists for some times. It can be established by 2xx responses to a INVITE request and identified by a Call-ID, a local tag, and a remote tag. Call is an informal term. Session is a multimedia connection and stream flows from a sender (caller) to a receiver (callee).

Provisional responses and Final responses, and SIP Transaction

A final response terminates a SIP transaction; all 2xx, 3xx, 4xx, 5xx, and 6xx responses. A provisional responses used by a server to indicate progress but does not terminate a SIP transaction; all 1xx responses. SIP transaction occurs between a client and a server. It comprises all messages from the first request sent from the client to the server up to a final (non-1xx) responses sent from the server to the client. If the final response to INVITE request is non-2xx, the transaction also includes ACK as another sub-transaction to the response.

Loose Routing and Strict Routing

Loose routing proxy keeps the present Request-URI in requests as it is and adds Record-Route header field. In this Record-Route header, "lr" parameter indicates loose routing. Record-Route header is added each loose routing proxy. It can be referred to RFC3261. Unlike loose routing, strict routing replaces the present Request-URI with next destination of hop based on RFC2543. Generally loose routing proxies are preferred.

Now based on this understanding these terms and structure, each UA and proxy server may be configured below. In this picture, a request is transmitted through blue arrows and a response is back into Alice's phone through brown ones.

SIP Header Fields

Here is SIP header field list based RFC 3261 and RFC 2543. With the table on the bottom of this post shows up most kinds of header fields in SIP even though the table is not sufficient for us to understand those headers clearly. With more pictures and flowchart, we need clarify some frequently used headers in practical approach.

CSeq and Call-ID headers vs. SIP transactions and Call (or Dialog)

Generally SIP transaction begins with SIP request sent from server to client and any response returned back from server to client. There are few exceptions like ACK, which does not need response. CSeq header (method + sequence number) is used to trace those SIP transactions.

A caller originates a call to a callee, and this whole procedure is observed as a dialog formally or a call informally. In a single dialog or call, several transactions are in there. Call-ID is used to trace a call or dialog.

In the picture above, INVITE and BYE transactions can be traced with CSeq method. ACK transaction is completed without response. Especially INVITE transaction has several provisional responses and final response with 2xx. And ACK transaction has the same sequence number as INVITE has and ACK as method, which means INVITE transaction absorbs ACK transaction.

From, To, and Via headers vs. Contact header and Source/Destination IPs

Where packet is sent is Source object and where it is heading for is Destination object. Whenever packet is transmitted, the source and destination objects are changed in Wireshark logs, and the objects could be IP addresses and TCP/UDP port numbers.

When a SIP request is initially sent from a caller to a callee, the caller's SIP-URI with a new tag is added on From header and the callee's on To header. Those SIP-URIs in From and To are not changed even in responses to the request. Once this request arrives at the callee, a receiver's new tag is added to To header.

Via header also defined according to who sends the initial request on a dialog. So From, Via, and To header fields follow who sends a initial SIP request per each call, which means these 3 information do not change before the call ends.

Beside these three headers, Contact header field is inserted according to who send SIP messages; request or response. On top of that, Contact header field includes more specific caller's information like protocol transport (such as TCP or UDP), and port number. It is usually composed of a username at FQDN (fully qualified domain name). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted.

So Contact header and source/destination IP addresses are changed per each message (both request and response) direction while From, Via, and To headers never changed in a call. Here is populated table above, helping us understand it.

Via and Max-Forwards headers vs. Hops

Via header field indicates the transport used for transaction and identities the location where the response is to be sent. It must has SIP 2.0 and a "branch" parameter. This branch parameter is used to identify the transaction created by that request and used by both the client and the server. When a response is sent, a "received" or "rport" parameter is added into the received Via field header. When the request is transferred to another element (called as a hop), additional Via field header is added to the existing one while Max-Forwards decreases by 1. When the response is transferred back to initial request originator, the top Via is removed in the end.

Here is more practical example in Wireshark. When a IMS client device under test can be connected to a network simulator, which including IMS proxy server as well as a virtual UA. Even though the IMS proxy server and the virtual UA locate in the same IP address, the functionality are totally separated.

Let's assume your device in IP address 192.168.1.1 and both proxy server and a virtual UA are in IP address 192.168.1.2. This is the case when your device is calling to the virtual UA.

No   Time      Source          Destination    Protocol
532  35.87..  192.168.1.1  192.168.1.2  SIP/SDP  Request: INVITE sip:0123456789@anritsu-cscf.com |
Internet Protocol Version 4, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: 45990 (45990), Dst Port: sip (5060)
Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:0123456789@anritsu-cscf.com SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 192.168.1.1:45990;branch=z9hG4bK..9191;rport
        Max-Forwards: 70

The IP addresses and UDP ports for both client and server sides are determined in the Wireshark log. UDP source port would be 45990 and destination port would be 5060 in this case. When a request is sent through Via path, transport layer port is defined as 45990 from the request side in your client. When Via header field is prepared, the "rport"(response-port) without port number is transferred to the server side in proxy server.

No      Time   Source          Destination    Protocol 
533  35.88..  192.168.1.2  192.168.1.1  SIP  Status: 100 Trying | 
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.1 (192.168.1.1)
User Datagram Protocol, Src Port: sip (5060), Dst Port: 45990 (45990)
Session Initiation Protocol (100)
    Status-Line: SIP/2.0 100 Trying
    Message Header
        Via: SIP/2.0/UDP 192.168.1.1:45990;branch=z9hG4bK..9191;rport=45990
        Max-Forwards: 70

In this response transport, the UDP source port would be 5060 and destination port would be 45990. When server side sends response with Via header, the response port number, 45990 is added to "rport".

We can think of another example when your device receive a call from the virtual UA. In this case, your device in IP address 192.168.1.11 and both proxy server and a virtual UA are in IP address 192.168.1.12.

No      Time           Source                Destination           Protocol
27  7.59..  192.168.1.12  192.168.1.11  SIP/SDP  Request: INVITE sip:+11234567890@192.168.1.11 |
Internet Protocol Version 4, Src: 192.168.1.12 (192.168.1.12), Dst: 192.168.1.11 (192.168.1.11)
User Datagram Protocol, Src Port: 65150 (65150), Dst Port: sip (5060)
Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:+11234567890@192.168.1.11 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 192.168.1.12:65150;branch=z9hG4bK..0186;rport;transport=udp
        Via: SIP/2.0/UDP 192.168.1.12:65144;branch=z9hG4bK..375a;rport=65146
        Max-Forwards: 69

There are 2 Via header fields. The UDP source port would be 65150 and destination would be 5060 for the the top Via header. When the request is sent through Via path, transport layer port is defined as 65150 from the client side in the proxy server. On Via header field, the "rport" without port number is sent to the server side in your UA.

The lower Via header field is generated by the virtual UA. The UDP source port cannot be found in the Wireshark log but transport layer port found as 65144. When this port is transferred through NAT, the IP address and transport port are bind to others based on RFC3581 6 Example. Since the server side in the proxy server understand that the request was sent from 65146 port number of the client. So rport with 65146 is added in the Via header field in the response.

No Time    Source            Destination      Protocol
28  7.64..  192.168.1.11  192.168.1.12  SIP  Status: 100 Trying |
Internet Protocol Version 4, Src: 192.168.1.11 (192.168.1.11), Dst: 192.168.1.12 (192.168.1.12)
User Datagram Protocol, Src Port: sip (5060), Dst Port: 65150 (65150)
Session Initiation Protocol (100)
    Status-Line: SIP/2.0 100 Trying
    Message Header
        v: SIP/2.0/UDP 192.168.1.12:65150;branch=z9hG4bK..0186;rport=65150;received=192.168.1.12;transport=udp
        v: SIP/2.0/UDP 192.168.1.12:65144;branch=z9hG4bK..375a;rport=65146

In the response transport, the UDP source port would be 5060 and destination would be 65150. When the response is sent from the server side in your device, rport with port number 65150 is inserted in Via header field.

Route and Record-Route headers vs. Via header

When a request arrives at a proxy, Record-Route header field can be added by a proxy. Here is an example, Record-Route: <sip:p1.example.com;lr>. "lr" indicates loose routing proxy. After all added Record-Route header fields arrives at the request's destination, the destination's UA copies all added Record-Route headers to 200 OK with SDP response. Unlike Via header, while 200 OK is delivered, those copied Record-Route headers are not removed per proxy but delivered to the caller.

Here is an example based on RFC3261 16.12 Summary of Proxy Route Processing.

Branch in Via header, Tag in From/To headers, and Call-ID header

Supported and Require headers 

Supported header field can contains what UACs support and it prevents servers from insisting non-standard or vendor specific features. Even though RFC specifications do not allow to use reliable provisional responses for any method but INVITE, Supported header field with "100rel" option tag can define a new mechanism and make it work. As matter of fact, all INVITE should include Supported header listing "100rel" option tag.

Require header field in a new request can be asked by UACs to servers that the client expects the server to support in order to properly process the request. If a server does not understand the option, 420 Bad Extension status code is returned. Require header with "100rel" option tag must not be used by any requests but INVITE.

Example:
C->S: INVITE sip:watson@bell-telephone.com SIP/2.0
           Require: com.example.billing
           Payment: sheep_skins, conch_shells
S->C: SIP/2.0 420 Bad Extension
           Unsupported: com.example.billing

path option-tag with Path header and with Route/Record-Route header fields 

If Path, Route and Record-Route header fields are used in transaction, "path" option-tag in Supported header field should be included in UA. The Path header field is a SIP extension header field with syntax very similar to the Record-Route header field.The Path header is used in conjunction with REGISTER requests and 200 responses while the Record-Route header is inserted into INVITE requests with the path vector, which was established by Path application for future dialogs.

A Path header field may be inserted into a REGISTER by any SIP node traversed by the request. The registrar reflects the accumulated Path back into the responses toward the originating UA. The originating UA is therefore informed of the inclusion of nodes on it's registered path vector and may use information in other capacities.

Home proxy rewrites the request-URI from the incoming request with the registered contact and retransmits the request. Home proxy also copies the stored path vector associated with specific contacts in the registrar database into Route header field of outgoing request.

Here is an example in RFC3327 for REGISTER operation. UA1 sends request to Registrar, which transmits its default outbound proxy P1, an intermediate proxy P2, and firewall proxy for the home domain, P3 before Registrar. Since P1 is home network targeted to UA1 and P3 needs to be sent by requests from Registrar, P1 and P3 have configured themselves in Path header fields on REGISTER requests and P2 have not.

This example shows how INVITE transaction originate from UA2 after UA1 has registered on Registrar above. Registrar inserts preloaded Route toward UA1 and retargets the by replacing the request URI with the registered Contact. Since Registrar does not want to be static route, it does not add Record-Route into the outgoing INVITE request.

SDP media level attributes

SDP (Session Description Protocol) description is transferred while SIP negotiated based on RFC 3312. There is list what media level attributes consists of below.

Here is an example how to map each type and tag to the media level attributes.

m=audio 20000 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv

There are many type of attributes' tags and clarify some of them direction perspective; "send", "recv", "local", and "remote". All messages are divided into Requests and Responses in SIP protocol while  description, all are done into "offer" and "answer". Each request or response can be either an offer or answer. In an offer, "send" is direction offerer -> answerer and "local" is the offerer's access network. In an answer, "send" is the direction answerer -> offerer and "local" is the answer's access network.

Here is SIP header field list.

Here is SDP header field list.

SIP Overview

While following IMS over LTE technology, RFC specifications base SIP study seems necessary to understand how IMS works in detail. It could be way different from 3GPP specifications, but it would be worth going through some of them.

Let me get started with one of most popular trapezoid example in RFC3261. This Figure 1 on right hand side comes from 4 Overview of Operation in RFC3261. And the left hand side one is draw by myself based on 24.2 Session Setup, which describe full detailed SIP message about Figure 1. As you can see these 2 trapezoids look quite different but I would rather follow 24.2 Session Setup with my chart from now on. 

Go through SIP Dialog

Since Alice's softphone does not know the location of Bob's SIP phone or SIP servers in biloxi.com domain, the softphone sends INVITE to it's SIP server that servers Alice's domain, atlanta.com. The address of atlanta.com SIP server could have been configured in Alice's softphone or discovered by DHCP. The atlanta.com proxy server receives INVITE request, processes it, and send 100 Trying response back to Alice's softphone. This 100 Trying response tells the caller that INVITE has been received an the atlanta.com proxy is working on her behalf to route the INVITE to the destination. 

The atlanta.com proxy server locates the proxy server at biloxi.com domain through DNS lookup, which is not in the chart. As a result, the IP address of biloxi.com proxy server is obtained and the INVITE request is forwarded by atlanta.com proxy. The biloxi.com proxy server receives INVITE and responses with 100 Trying back to atlanta.com to indicate it was received. Generally the callee's proxy server (biloxi.com in this case) consults a database to locate the callee.

As soon as Bob's SIP phone receives the INVITE and alerts Bob to incoming call from Alice so that Bob can decide whether to answer the call. This makes Bob's phone ring while sending a 180 Ringing response, which is routed back through the 2 proxies. 

Bob decides to answer the call in this example. When he picks up the handset, a 200 OK response is sent to indicate that the call has been answered. This 200 OK contains SDP media description of session type that Bob is willing to establish with Alice. Then the requester responses ACK to 200 OK and this ACK is directly routed to the callee. After this, media session has now established and real media can be transmitted, we say.

At the end of the call, Bob hangs up first, which generate a BYE message. This BYE is routed directly to the caller, Alice bypassing those proxies. Alice confirms the receipts of BYE with 200 OK response, which terminates the session and the BYE transaction. 

So far, narrowing down some related header fields would be helpful. Here is the final detailed SIP message on the trapezoid below.

# References

• RFC3261 4 Overview of Operation
• RFC3261 24.2 Session Setup

LTE UE Measurements a little bit more

There are several IEs to configure measurement control in detail, which are under measConfig IE in RRC Connection Reconfiguration message. They are not clearly described with specific picture but here is what I understand.

Form the top picture, we might think of an ideal case as (neighbour) cell measured value in yellow goes up linearly. Threshold is bottom line and offset (including several kinds of sub-offset values though) and hysteresis can be applied. Entering condition in this case would mean yellow line cross over threshold (+hysteresis) with blue "x" mark. From this point, timeToTrigger and reportInterval can be applied through the blue block. Leaving condition in this case could not be applied because it never get down go threshold (-hysteresis) as grey "x" mark. If measConfig needs to be removed, it can be managed by RRC Connection Reconfiguration procedure. From the bottom one, we can think of entering and leaving condition with blue "x" marks. At least leaving condition seems like buffer in order to keep UE measurement as steady as possible and avoid cell measured value fluctuated. There are two types of reportConfig - triggerType; event and periodical.

Trigger Type - Event

Measurement control with event trigger type (triggerType IE) allows UE do measure on its own and report it if it meets the criteria as the type configured. The concept of Measurement Events can be illustrated below, which is same way network emulators use in. The allocation of each event is my intent to show same logic of events; Event A3, A4, and A5 have same logic A6, B1, and B2.

According to 3GPP specs, each event has both entering and leaving condition. Entering condition is met from blue x mark and the report activity is supposed to be kept through the blue box area. Leaving condition can be ignored in order to understand how they work even though it is marked as grey x.

• Event A1 (Serving becomes better than threshold)
• Entering condition: Ms > Thresh + Hys
• Leaving condition: Ms < Thresh - Hys
• Event A2 (Serving becomes worse than threshold)
• Entering condition: Ms < Thresh - Hys
• Leaving condition: Ms > Thresh + Hys
• Event A3 (Neighbour becomes offset better than PCell)
• Entering condition: Mn > Ms + Thresh + Hys + offset
• Leaving condition: Mn < Ms + Thresh + Hys + offset
• Event A4 (Neighbour becomes better than threshold)
• Entering condition: Mn > Thresh + Hys - offset
• Leaving condition: Mn < Thresh - Hys - offset
• Event A5 (PCell becomes worse than threshold1 and neighbour becomes better than thrreshold2)
• Entering condition: Ms < Thresh1 - Hys & Mn > Thresh2 + Hys - offset
• Leaving condition: Ms > Thresh1 + Hys & Mn < Thresh2 - Hys - offset
• Event A6 (Neighbour becomes offset better than SCell)
• Entering condition: Mn > Ms + Hys + offset
• Leaving condition: Mn > Ms + Hys + offset
• Event B1 (InterRAT neighbour becomes better than threshold)
• Entering condition: Mn > Thresh + Hys - offset
• Leaving condition: Mn < Thresh - Hys - offset
• Event B2 (PCell becomes worse than threshold1 and interRAT neighbour becomes better than thrreshold2)
• Entering condition: Ms < Thresh1 - Hys & Mn > Thresh2 + Hys - offset
• Leaving condition: Ms > Thresh1 - Hys & Mn < Thresh2 + Hys - offset

Event B1 and B2 have the same logic as Event A4 and A5 have. Event A6 has exactly same logic as Event A3 has but relation between LTE SCell and neighbour cells. Event A6 must be considered under CA (Carrier Aggregation) and neighbour LTE cell environment. You may notice Ms (Measurement result of serving) and Mn (for neighbour). Offset was described above.

IEs described above are pretty much straightforward, which can be found in TS36.331 5.5.4 Measurement report triggering. Offset for Event A3 would be offsetFreq + cellIndividualOffset (under measObjectEUTRA to serving) + offsetFreq + cellIndividualOffset (under measObjectEUTRA to neighbour) + a3offet (under reportConfigEUTRA). Offset for Event A4 and A5 would be offsetFreq + cellIndividualOffset (under measObjectEUTRA to neighbour).
In order to configure report config, these kinds of IE nodes are required below. Here are two examples.

ReportConfigToAddMod

    reportConfigId: 1
        reportConfig: reportConfigEUTRA (0)
            reportConfigEUTRA
                triggerType: event (0)
                    event
                        eventId: eventA5 (4)
                            eventA5
                                a5-Threshold1: threshold-RSRP (0)
                                    threshold-RSRP: -90dBm (50)
                                a5-Threshold2: threshold-RSRP (0)
                                    threshold-RSRP: -80dBm (60)
                        hysteresis: 1dB (2)
                        timeToTrigger: ms320 (8)
                    triggerQuantity: rsrp (0)
                    reportQuantity: both (1)
                    maxReportCells: 1
                    reportInterval: ms1024 (4)
                    reportAmount: r8 (3)

ReportConfigToAddMod
    reportConfigId: 1
        reportConfig: reportConfigEUTRA (0)
            reportConfigEUTRA
                triggerType: event (0)
                    event
                        eventId: eventA3 (2)
                            eventA3
                                a3-Offset: 0dB (0)
                                .... .0.. reportOnLeave: False
                        hysteresis: 1dB (2)
                        timeToTrigger: ms640 (11)
                    triggerQuantity: rsrp (0)
                    reportQuantity: both (1)
                    maxReportCells: 1
                    reportInterval: ms1024 (4)
                    reportAmount: r8 (0)



# References

• TS36.331 5.5.4 Measurement report triggering
• TS36.331 6.3.5 Measurement information elements

RSRP - Allowed Measurement Bandwidth

UE performs measurements within the allowed measurement bandwidth (allowedMeasBandwidth IE under measObject IE), which is different from system bandwidth or transmission bandwidth. It is allowed to be chosen from mbw6 through mbw100 within the system bandwidth. TS36.214 says RSRP measurement is defined within the measurement bandwidth, which is found more specifically, within 6 RB (mbw6) in TS36.133. This is also can be found as measurement bandwidth for reelection and handover between different frequency carriers in TS36.521-3 RRC conformance testing spec. This is definition of RSRP in TS36.214 5.1.1 Reference Signal Received Power. 

Reference signal received power (RSRP), is defined as the linear average over the power contributions (in [W]) of the resource elements that carry cell-specific reference signals within the considered measurement frequency bandwidth.

The real reported RSRP measurement values can be mapped to dBm value below. Typically we would think of "IE value - 140 = dBm value" though.

# References

• TS36.214 5.1.1 Reference Signal Received Power (RSRP)
• TS36.133 8.1.2.3 E-UTRAN inter frequency measurements
• TS36.133 9.1.4 RSRP Measurement Reporting Mapping

L3 Filtering

Before moving to L3 filtering, we better think of what really happens during measurement on UE side. Here is how TS36.300 explained on measurement model. UE internal layer 1 filtering at point A is actually implementation dependent and not constrained by the standard.

Whenever UE L1 does measurements, the measured values are reported to RRC layer through L3 filtering; B and C above. Measured results are input of L3 filtering and the output of this filtering is reported to RRC layer. The filter function (equation) is defined in TS36.331 and requires a filter coefficient parameter value ( filterCoefficient IE), which is delivered by measurement control over RRC Connection Reconfiguration procedure. RRC does not seem like remembering any previous reported values and just evaluating reported values with criteria. One internal measurement path reports C and another does C, which are compared each other in RRC layer if requested by measurement control over RRC Connection Reconfiguration procedure. Finally if internal reported value fulfills the criteria, RRC prepares to report it through air link, which is called Measurement Report message.

What kind of parameter is delivered to layer 3 filtering from RRC is as follows. This is one of example under RRC Connection Reconfiguration message.

quantityConfig

    quantityConfigEUTRA

        filterCoefficientRSRP: fc4 (4)

        filterCoefficientRSRQ: fc4 (4)

This value is applied to layer 3 filtering, which is the function below. As you can see, this is moving average function, which makes the output smooth. Any particular reported one caused by uncertain reason could meet criteria and send Measurement Report to the air. So layer 3 filtering can avoid this unexpected instant value, which could get network side confused.

If filterCoefficient is 0 to 3, the output is equal to 0. The minimum value is fc4 (4), which is default one for LTE. The layer 3 filtering function (equation) and the default value are various depending on technology below.

# References

• TS36.300 10.6 Measurement Model
• TS36.331 5.5.3.2 Layer 3 filtering
• TS36.331 6.3.5 Measurement information elements

Measurement gap

UE shall be capable of monitoring max. 54 carriers including all RATs using gaps. In addition to this requirements, UE shall be capable of monitoring at least 7 carrier frequency layers comprising of any combination of E-UTRA FDD, E-UTRA TDD, UTRA FDD, UTRA TDD, and GSM layers, cdma2000 1x and HRPD layers. TS36.300 shows scenario A to C show us intra frequency handover whereas D to E do inter frequency, which requires measurement gap.

A cell shall be recognized by UE within 480 ms defined as TBasic_Identity_Inter. Depending on how many carriers are monitored, inter-frequency measurement time is allowed UE to use in total, which is defined as TIdentity_Inter. TInter1 can be 60 or 30 ms depending on gap pattern ID. N freq is number of carriers for all RATs but GSM. If it is equal to 0 if no GSM carrier is being monitored and 1 if up to 32 is being done for MGRP of 40 ms. This total timeout can be used in in TS36.521-3 RRC conformance testing spec.

And here is here is how exactly measurement gap works on LTE physical layer below. Measurement gap is higher priority than any other activity such as DRX, HARQ, or UL grant transmission.

# References

• TS36.331 5.5.2.9 Measurement gap configuration
• TS36.133 8.1.2.1 UE measurement capability