Amazing Holes on Earth

Amazing Scary Holes on Earth!!
7 amazing holes

Apparently the largest ever hand-dug excavation in the world, this 1097 metre deep mine yielded over 3 tonnes of diamonds before being closed in 1914.
the amount of earth removed by workers is estimated to total 22.5 million tonnes.




Glory hole - Monticello dam
a glory hole is used when a dam is at full capacity and water needs to be drained from the resevoir.




This is the glory hole belonging to monticello dam in california and it ??s the largest in the world, its size enabling it to consume 14 ??400 cubic feet of water every second.



The hole can be seen at the top left of the photo above. if you were to jump in for some reason your slightly damp body would shoot out near the bottom of the dam .




Bingham canyon mine, utah
This is supposedly the largest man-made excavation on earth. extraction began in 1863 and still continues today, the pit increasing in size constantly. in its current state the hole is 3/4 mile deep and 2.5 miles wide.



Great blue hole, Belize
situated 60 miles off the mainland of belize is this incredible ??geographical phenomenon ?? known as a blue hole. there are numerous blue holes around the world but none as stunning as this one.



At surface level the near perfectly circular hole is 1/4 mile wide, the depth in the middle reaching 145 metres. obviously the hole is a huge hit with divers.

Beauty of Paintings - Feature paintings

CIFS Packet Structure

Packet Header:
Every CIFS request and response uses the packet header below as a template. The various fields are described after the template.



Header: The beginning of every CIFS packet contains a 4-byte header. The first byte is 0xFF, followed by the ASCII representation of the letters ‘S’, ‘M’, and ‘B’.
Command: The command field contains a one-byte code indicating the CIFS packet type. Examples from the CIFS1.0 draft for this field are SMB_COM_READ_ANDX7 (0x2E), SMB_COM_TREE_CONNECT (0x70), and SMB_COM_NEGOTIATE (0x72).

Error class: A server indicates whether or not a given request was successful with the error class field. Typically, the field is zero, indicating success. If non-zero, the field indicates what class the error code is from. When set, the error class field takes one of the following values:
• ERRDOS (0x01) – Error is from the core DOS operating system set
• ERRSRV (0x02) – Error is generated by the server network file manager
• ERRHRD (0x03) – Hardware error
• ERRCMD (0xFF) – Command was not in the “SMB” format

Error code: This 16-bit field indicates the type of error that has occurred. It is typically set to zero, indicating no error. If set, this number in conjunction with the error class above can be looked up in the CIFS1.0 draft to give full error descriptions,such as “bad password” or “file does not exist”. As with the error class, this field is set only by servers in response to a previous request.
Flags: Most of the 8 bits in the flags field specify particular options. The only one of note in this field is bit 3. When bit 3 is set to ‘1’, all pathnames in this particular packet must be treated as caseless. When bit 3 is set to ‘0’, all pathnames are case sensitive.

Flags2: This 16-bit field specifies more options. Bits that are useful:
• Bit 0, if set, indicates that the server may return long file names in the response.
• Bit 6, if set, indicates that any pathname in the request is a long file name.
• Bit 16, if set, indicates strings in the packet are encoded as UNICODE.
Pad/security signature: This field is typically set to zero.
Tree ID (TID): The TID is a 16-bit number that identifies which resource (disk share or printer, typically) this particular CIFS packet is referring to. When packets are exchanged which do not have anything to do with a resource, this number is meaningless and ignored.

If a client wishes to gain access to a resource, the client sends a CIFS packet with the command field set to SMB_COM_TREE_CONNECT_ANDX. In this packet, the share or printer name is specified (i.e. \\SERVER\DIR). The server then verifies that the resource exists and the client has access, then sends back a response indicating success. In this response packet, the server will set the TID to any number that it pleases. From then on, if the client wishes to make requests specific to that resource, it will set the TID to the number it was given.

Process ID (PID): The PID is a 16-bit number that identifies which process is issuing the CIFS request on the client. The server uses this number to check for concurrency issues (typically to guarantee that files will not be corrupted by competing client processes).

User ID (UID): The UID is 16-bit number that identifies the user who is issuing CIFS requests on the client side. The client must obtain the UID from the server by sending a CIFS session setup request containing a username and a password. Upon verifying the username/password, the server responds to the session setup and includes a generated UID. The client then uses the assigned UID in all future CIFS requests. If any of these client requests require file/printer permissions to be checked, the server will verify that the UID in the request has the necessary permissions to perform the operation.

A UID is valid only for the given NetBIOS session. Other sessions could potentially be using an identical UID that the server correlates with a different user. Note: if a
server is operating in share level security mode (see above), the UID is meaningless and ignored.

Multiplex ID (MID): The MID is a 16-bit value that is used to allow multiple outstanding client requests to exist without confusion. Whenever a client sends a CIFS packet, it checks to see if it has any other unanswered requests pending. If it does, it insures that the new request will have a different MID then the previously outstanding requests. Whenever a server replies to a CIFS request, it insures that the response it sends matches the request MID that it received. In following this procedure, the client can always know exactly which outstanding request an incoming reply is correlated to.

WordCount and parameter words: CIFS packets use these two fields to hold command-specific data. The CIFS packet header template above cannot hold every possible data type for every possible CIFS packet. To remedy this, the parameter words field was created with a variable length. The wordcount specifies how many 16-bit words the parameter words field will actually contain. In this way, each CIFS packet can adjust to the size needed to carry its own command-specific data.

The wordcount for each packet type is typically constant and defined in the CIFS1.0 draft. There are two wordcounts defined for every single command; one wordcount for the client request and another for the server response. Two counts are needed because the amount of data necessary to make a request is not necessarily the same amount needed to issue a reply.

ByteCount and buffer: These fields are very similar to the wordcount and parameter words fields above; they hold a variable amount of data that is specified on a per packet basis. The bytecount indicates how many bytes of data will exist in the buffer field that follows.

The major difference between the parameter data section above and the buffer is what type of data they store. The parameter words data section typically holds a small number of packet options, while the buffer data section typically holds large amounts of raw data (e.g. file data).

Packet Sequence Walkthroughs:
Two common CIFS client/server packet exchanges are presented below. The first exchange shows what packets are sent when a client first initiates contact with a server: a NetBIOS session is established, a CIFS dialect is negotiated, a username and password are sent, and finally, a resource (such as a printer or directory share) is connected to. The second exchange examines the packets required to open a file and read from it.

For each exchange, an initial summary gives an overview of the entire process. In addition, each packet that is sent and received is detailed (by listing out the various packet header values) and also summarized.
Note that in all examples, the client always sends to TCP port 139, and the server always replies to the ephemeral port number that is chosen by the client. In addition, the following CIFS packet fields will not be described for each individual packet:

• Error class/code – always zeros when sent from client and assumed to be zeros when returned from server (the examples do not cover error scenarios).
• Flags – set to 0x00 for all packets (case sensitive pathnames)
• Flags2 – set to 0x0001 for all packets (long file name support)
• Pad/security signature – Set to zero in all packets

Initial contact, login, and tree connect:
When a CIFS client determines that it wishes to access resources on a CIFS server, the following packet sequence is exchanged. First, a NetBIOS session is established in order to provide a reliable message sequence transport service. Then, the client and server negotiate the CIFS dialect in which they will be communicating. The client then logs into the server, sending a username and password (for this example, the server will be operating in user level security). Finally, the client connects to the desired resource.
Packet #1 request, client –► server
Purpose: Establish NetBIOS session
Summary:
The client, wishing to exchange CIFS packets with the server, initiates a NetBIOS session between itself and the server (referred to as “calling the server” in the previous NetBIOS section). This provides for sequenced, reliable message delivery between the two endpoints. Note that the client must know the server’s NetBIOS name in order to call it and also must indicate its own NetBIOS name.

The events to establish the NetBIOS session are as follows. First, the client establishes a full duplex TCP connection with the server on port 139. Once this is accomplished, the client builds and sends a NetBIOS session request packet (not diagrammed in the NetBIOS section above, but described in RFC1002) over the TCP connection. In summary, the session request packet contains the client’s NetBIOS name, the server’s NetBIOS name, and an integer constant which indicates the packet’s purpose is to establish a NetBIOS session. Please see RFC1002 for more details.
Packet #2 response, server –► client
Purpose: Positive NetBIOS session acknowledgement
Summary:
If the above session request packet contained the server’s NetBIOS name, and the packet was formatted correctly, the server replies with a simple session established acknowledgement. This 4-byte packet is also described in RFC1002. In summary, it indicates either a successful session establishment or an error code.
Packet #3 request, client –► server
Purpose: Negotiate CIFS dialect
Summary:
Now that the NetBIOS session is established, the client is ready to send the first real CIFS request. The client sends the SMB_COM_NEGOTIATE command and includes a list of CIFS dialects that it understands.
Packet:
Command: SMB_COM_NEGOTIATE (0x72)
TID: Ignored in this packet.
PID: Set to process ID of client process.
UID: Ignored in this packet.
MID: Any unique number.
WordCount: 0
ParameterWords: There are none because wordcount is 0.
Bytecount: Set to 119 (variable depending on how many CIFS dialects the client understands).
Buffer: Contains 119 bytes worth of dialect descriptions, examples would be as follows: “PC NETWORK PROGRAM 1.0”, “MICROSOFT NETWORKS 3.0”, “DOS LM1.2X002”, “DOS LANMAN2.1”, “Windows for Workgroups 3.1a”, “NT LM 0.12”.
Packet #4 response, server –► client
Purpose: Choose CIFS dialect from request list
Summary:
The server is now responding to the negotiate protocol request by selecting the dialect that it wishes to communicate in.
Packet:
Command: SMB_COM_NEGOTIATE (0x72)
TID: Ignored in this packet.
PID: Ignored when packet is from server.
UID: Ignored in this packet.
MID: matches unique number chose above.
WordCount: This number depends on the dialect that is chosen. For this example, we will assume that the server chose “NT LM 0.12”8. In this case, the wordcount is 17.
ParameterWords: The 17 words contained here indicate the chosen dialect and many server properties. Of note is the MaxMpxCount (which states the max number of pending requests the client can initiate) and the 32-bit capabilities flags (which indicate if UNICODE is supported, if large files are supported, if NT commands are supported, and more).
Bytecount: Variable, usually greater than 8.
Buffer: Typically contains an 8-byte random string that the client uses in the next packet for encryption purposes.
Packet #5 request, client –► server
Purpose: User login
Summary:
Now that the CIFS dialect has been agreed upon, the client sends a packet containing a username and password to gain a user ID (UID). This packet also relays client capabilities to the server, so the packet must be sent even if the server is using share level security.
Packet:
Command: SMB_COM_SESSION_SETUP_ANDX (0x73)
TID: Ignored in this packet.
PID: Set to process ID of client process.
UID: Ignored in this packet.
MID: Any unique number.
WordCount: 12
ParameterWords: This section is very similar to the server’s negotiate protocol parameter words response. However, instead of listing the server’s capabilities, it lists the client’s. It also contains the size of the passwords to be supplied in the buffer section below.
Bytecount: Variable, the buffer below contains the encrypted password, the username, the name of the operating system and the native LAN manger. Therefore, the size listed here depends on the string sizes of all these entities.
Buffer: As mentioned above, this field actually contains the password, username, and other strings that identify the operating system involved.
Packet #6 response, server –► client
Purpose: Indicates User ID (UID) or returns error if bad password
Summary:
Once the server receives the encrypted password and username, it checks if the combination is valid. If the password is invalid, this response packet will be returned with the error class and code set to the appropriate error value. If the username/password is correct, then this packet contains the UID that the client will begin to send with every packet from here on.
Packet:
Command: SMB_COM_SESSION_SETUP_ANDX (0x73)
TID: Ignored in this packet.
PID: Ignored when packet is from server.
UID: The 16-bit number that the server has assigned to represent client user identity.
MID: Matches unique number chose above.
WordCount: 3
ParameterWords: Nothing relevant to normal operation.
Bytecount: Variable, the buffer below contains strings stating the server OS and native LAN manager type.
Buffer: Contains strings indicating the server OS and LAN manager type.
Packet #7 request, client –► server
Purpose: Connect to particular resource
Summary:
At this point, the client has authenticated itself to the server and may proceed to connect to the actual share. In this packet, the client specifies the share that it wishes to access. Share names are specified in UNC format (i.e. \\SERVER\SHARE).
Packet:
Command: SMB_COM_TREE_CONNECT_ANDX (0x75)
TID: Ignored in this packet.
PID: Set to process ID of client process.
UID: Set to the server returned UID from the above session setup response.
MID: Any unique number.
WordCount: 4
ParameterWords: Nothing relevant to normal operation.
Bytecount: Variable, depends on the size of the UNC string that is requested below.
Buffer: Contains the share name that the client wishes to access.
Packet #8 response, server –► client
Purpose: Indicates Tree ID (TID) or error if share name does not exist
Summary:
If the share specified above exists and the user has access permission, then the server returns a successful response with the TID set to the number it wishes to refer to the resource as. If the share does not exist or the user does not have access permission, the server will return the appropriate error class and error code here. Assuming that this packet indicates success, the client now has everything it needs to access files from the specified share. This is the final packet in this client/server exchange.
Packet:
Command: SMB_COM_SESSION_SETUP_ANDX (0x73)
TID: 16-bit number which server has assigned to represent the requested resource.
PID: Ignored when packet is from server.
UID: 16-bit number representing the user.
MID: Matches unique number chosen above.
WordCount: 3
ParameterWords: Nothing relevant to normal operation.
Bytecount: Variable, the buffer below contains strings stating the native file system and device type of the requested resource.
Buffer: Contains strings that state the native file system and device type.
File open and read:
Once a client has completed the initial packet exchange sequence described above, it may open and read files from the share that was requested. The file open consists of one CIFS request and one CIFS response. The read request also consists of one request and one response packet.
Packet #1 request, client –► server
Purpose: Open a file
Summary:
In order to read or write to a file, it first must be opened. This CIFS packet does exactly that.
Packet:
Command: SMB_COM_OPEN_ANDX (0x2D)
TID: Set to the server returned TID from the tree connect response above.
PID: Set to process ID of client process.
UID: Set to the server returned UID from the session setup response above.
MID: Any unique number.
WordCount: 15
ParameterWords: Specifies many open options such as mode (read, write, or readwrite) and sharing mode (none, read, write).
Bytecount: Variable, depends on the size of the string that contains the filename.
Buffer: Contains the name of the file to be opened.
Packet #2 response, server –► client
Purpose: Indicate File ID, or error code if problem
Summary:
The server checks to see if the filename above exists and if the user specified in the UID has permission to access the file. If these conditions are not met, the server will return the appropriate error class and error code indicating what that problem is. If there are no errors, the server returns a response packet that includes a File ID (FID) that can be used in subsequent packets for accessing the file. Note that the FID is returned to the client in the parameter words field of the response. There is no FID field in the standard CIFS header.
Packet:
Command: SMB_COM_OPEN_ANDX (0x2D)
TID: 16-bit number which the server assigned to represent the requested resource.
PID: Ignored when packet is from the server.
UID: 16-bit number representing the user.
MID: Matches unique number chosen above.
WordCount: 15
ParameterWords: Many flags indicating what type of actions occurred and the very important 16-bit FID.
Bytecount: 0
Buffer: No data in buffer.
Packet #3 request, client –► server
Purpose: Read from a file
Summary:
Assuming that the above response indicated a FID for the client to use, an actual read request for file data can now be issued.
Packet:
Command: SMB_COM_READ_ANDX (0x2E)
TID: Set to the server-returned TID from the tree connect response above.
PID: Set to process ID of client process.
UID: Set to the server-returned UID from the session setup response above.
MID: Any unique number.
WordCount: 10
ParameterWords: Here, the FID is stated so the server knows which opened file the client is referring to. Also indicated here are a 32-bit file offset and a 16-bit count value. These two numbers dictate where and how much data to return from the file.
Bytecount: 0
Buffer: No data in buffer.
Packet #4 response, server –► client
Purpose: Returns file data requested
Summary:
This packet contains the requested file data. Assuming the UID, TID, and FID were all valid numbers in the request, an error here should be unlikely.
Packet:
Command: SMB_COM_READ_ANDX (0x2E)
TID: 16-bit number which server has assigned to represent the requested resource.
PID: Ignored when packet is from the server.
UID: 16-bit number representing the user.
MID: Matches unique number chosen above.
WordCount: 12
ParameterWords: Here, the number of bytes that were actually read is indicated. This does not necessarily match the number requested (in case the request exceeded the file boundary).
Bytecount: Variable, the buffer holds the file data, so this number is also the number of bytes that were actually read.
Buffer: The file data requested.

CIFS Internals

In a nutshell, the Common Internet File System (CIFS) is a network protocol that allows file sharing between network nodes. The protocol is based around a client server design where the client sends request packets to the server, and the server responds back to the client with response packets. Each packet that is sent contains a standard header, plus two variable length fields that are used for packet specific information. Each packet also contains a command field that indicates the general purpose the packet is trying to accomplish. Common command fields indicate that the packet’s purpose is to login, open a file, read from a file, or write to a file.
To gain a more in-depth understanding of the protocol, there are three detailed sections on CIFS below. The first section covers major protocol properties. The second section introduces the CIFS standard packet header by diagramming the various fields and defining their purpose. The final section has two typical packet sequence walkthroughs: logging into a server and a file open/read.

Protocol Properties:
Client/server + request/response: As mentioned above, the CIFS architecture is based upon a client sending requests and a server replying to each request sent5. The protocol is capable of having multiple simultaneous requests outstanding. This is accomplished through the use of a multiplex id (MID). The client insures that every request that is sent to the server has a unique MID. When the server replies to a given request, the response contains the same MID. In this way, multiple requests can be sent to the server, and the client can simply match the response MID with the MID it generated to know which request has just been replied to.

Command based: Each CIFS packet contains a 1-byte command field. There are currently 100+ commands available and the core functionality of each packet revolves around the specified command. Responses to the client always have the same command code as the request. A list of common command codes is available within the CIFS1.0 draft specification.

Protocol dialects/negotiation: There have been many versions of the CIFS protocol since its inception in the 1980’s. Each protocol version is referred to as a dialect and is assigned a unique string to identify the dialect such as “PC NETWORK PROGRAM 1.0” or “NT LM 0.12”. When a client wishes to access files on a remote server, the first CIFS packet that is sent is a negotiate protocol packet. In this CIFS packet, the client lists all of the dialect strings that it is capable of understanding. In the response packet, the server indicates which dialect it wishes to communicate in, or indicates that the server understood no dialects. In this way, the client and server can negotiate which dialect to use for a particular CIFS session.
User/share level security: A share is a server entity (typically a file folder or printer) that is tagged as available to CIFS clients for network sharing. Restricted access to the share is brought about in one of two ways:
1. User level security: Indicates that a client wishing to access the share must provide a username and a password for access. This provides the server administrator fine grain control over who has access to the share. This type of security is used in Windows NT and Windows 2000.
2. Share level security: Indicates that the share itself requires a password to access, but no username is required and no user identity is established. For example, a password X could be assigned to a certain share. Any user knowing password X can then gain access to the share. There is no fine grain control because there is no concept of individual users and their rights. This type of security is used in Windows 95 and 98.
Encryption: For either of the two security methods above, the actual password is sent in an encrypted format to the server6. There are two encryption methods that are commonly used: the newer NT style and the older LAN Manager style. Both encryption methods use challenge-response authentication, where the server sends the client a random string and expects a response that proves the client knows both the random string and the user password.
Command batching: Many CIFS packets are capable of piggybacking other CIFS packets in order to reduce response latency and better utilize network bandwidth. This technique is referred to as ANDX batching.
Opportunistic locking: When a CIFS packet specifies to open a file, an opportunistic lock (oplock) can be requested. If granted by the server, the oplock indicates to the client that no other entities are accessing the file. This allows the client to make any modifications to the file that it wants and not have to write them all to the server immediately. There are multiple types of oplocks and many nuances to them. See the CIFS1.0 draft specification for more information.

Common Internet File System - CIFS

What is CIFS?
The Common Internet File System (CIFS), also known as Server Message Block (SMB), is a network protocol whose most common use is sharing files on a Local Area Network (LAN). The protocol allows a client to manipulate files just as if they were on the local computer. Operations such as read, write, create, delete, and rename are all supported – the only difference being that the files are not on the local computer and are actually on a remote server.
The CIFS protocol works by sending packets from the client to the server. Each packet is typically a basic request of some kind, such as open file, close file, or read file. The server then receives the packet, checks to see if the request is legal, verifies the client has the appropriate file permissions, and finally executes the request and returns a response packet to the client. The client then parses the response packet and can determine whether or not the initial request was successful.
CIFS is a fairly high-level network protocol. In the OSI model, it is probably best described at the Application/Presentation layer. This means CIFS relies on other protocols for transport. The most common protocol used for reliable transport is NetBIOS over TCP (NBT), which will be described in the NetBIOS chapter below. Other protocols have been used for the transport layer, however with the enormous popularity of the Internet, NBT has become the de-facto standard.
Although file sharing is CIFS’s primary purpose, there are other functions that CIFS is commonly associated with. Most CIFS implementations are also capable of determining other CIFS servers on the network (browsing), printing, and even complicated authentication techniques. None of these subjects will be discussed in this document however, only the basics of CIFS file operations.

Where is CIFS?
The CIFS protocol is most commonly used with Microsoft operating systems. Windows For Workgroups was the first Microsoft operating system to use CIFS, and each Microsoft operating system since then has been able to function as both a CIFS server and client. Microsoft operating systems use CIFS for remote file operations (typically mapping network drives), browsing (via the Network Neighborhood icon), authentication (NT and Windows 2000), and remote printer services. It would be fair to say the core of native Microsoft networking is built around its CIFS services.
Because of Microsoft’s large corporate and home user base, the CIFS protocol is found virtually everywhere. Flavors of the Unix operating system also implement a CIFS client/server via the Samba program. Apple computers also have CIFS clients and servers available, which might make CIFS the most common protocol for file sharing available.

Enhanced Data rates for GSM Evolution - EDGE

EDGE, a new radio interface technology with enhanced modulation, increases the HSCSD and GPRS data rates by up to three fold. EDGE modulation will increase the data throughput provided by the packet switched service even over 400 kbit/s per carrier. Similarly, the data rates of circuit switched data can be increased, or existing data rates can be achieved using fewer timeslots, saving capacity. Accordingly, these higher speed data services are referred to as EGPRS (Enhanced GPRS) and ECSD (Enhanced Circuit Switched Data).

EDGE, expected to be deployed in 2000–2001, is a major improvement in GSM phase 2+. As a modification to existing GSM networks, EDGE does not require new network elements.

EDGE is especially attractive to GSM 900, GSM 1800 and GSM 1900 operators that do not have a licence for UMTS, but still wish to offer competitive personal multimedia applications utilising the existing band allocation. Also, EDGE can co-exist with UMTS, for instance to provide high speed services for wide-area coverage while UMTS is deployed in urban hot spots.

In the US, EDGE is part of the IS-136 High Speed concept which is one of the third generation RTT (Radio Transmission Technology) proposals from TR45. EDGE will be also standardised in US which makes possible to achieve a global mobile radio system with many services characteristic to third generation systems.

Nokia is dedicated to supporting GSM operators with wireless data solutions that help them create value in the market place, both now and in the future. Wireless data is steady evolution, not revolution. With Nokia’s experience, the operator starting today with wireless data can accumulate the skills and know-how to build a strong market position, all the way to third generation systems and the personal multimedia era. This White Paper describes Nokia’s understanding of the role and benefits of EDGE as wireless data evolves towards personal multimedia.

EDGE

The GSM standard is being developed to support mobile services with radio interface data rates even over 400 kbit/s. This work is being performed under the ETSI work item EDGE (Enhanced Data Rates for GSM Evolution).

The major change in the GSM standard to support higher data rates is the new modulation system, known as 8PSK (Phase Shift Keying). This will not replace but rather co-exist with the existing GMSK (Gaussian Minimum Shift Keying) modulation. With 8PSK, it is possible to provide higher data rates with a somewhat reduced coverage, whereas GMSK will be used as a robust mode for a wide area coverage.
EDGE brings more speed and capacity when needed

In mature GSM markets, cellular data penetration is forecast to increase exponentially during the early 2000’s. New wireless data applications and innovative
terminal types will generate completely new markets: aggressive GSM operators can expect to obtain up to 30 % of their airtime and revenue from wireless data by year 2000.

HSCSD (High Speed Circuit Switched Data) and GPRS (General Packet Radio Service), introduced to GSM in 1998 and 1999 respectively, will enable cellular operators to offer higher than 9.6 kbit/s data rates to their subscribers for new data applications.

Cellular operators that have invested in HSCSD and GPRS expect to be able to offer higher data rates without building too many new sites. The ECSD (Enhanced Circuit Switched Data) and EGPRS (Enhanced General Packet Radio System) solutions offer data services comparable to 3rd generation levels with considerably fewer radio resources than in standard GSM. This means that EDGE TRXs (transceivers) carry more data per time slot, decreasing the need for new TRXs/frequencies. In addition, end user response times decrease, ensuring good service levels as data usage increases.

It could be possible for EDGE Phase 2 to provide a voice service using AMR (Adaptive Multirate Codec) type of solution. EDGE TRXs would then be capable of carrying multiple speech calls per time slot, increasing voice capacity. Also, high quality codecs, e.g 32 kbit/s, would be feasible. EDGE as a voice solution looks especially
interesting for indoor systems because of it’s scalable capacity.

Enhanced Uplink DedicatedChannel - Mobile Technology -II

Due to the non-orthogonal uplink transmission in W-CDMA the principles applied for the newly defined
transport channel Enhanced Dedicated Channel (E-DCH) are fundamentally different from HSDPA.
The shared resource in the system is the received interference at the Node B and a transmission at a single
UE can impact the raise over thermal noise as received by different Node B. Continuous uplink power
control is still an essential means of link adaptation due to the well known near-far problem. Consequently
it was decided to support soft handover for E-DCH to minimize intercell interference. Unlike HSDPA
the scheduler is not aware of the transmission buffer status, channel state and the UE transmission capabilities.
Partly this information will be signalled to the Node B via control signalling.
For the support of the new functionality several new physical channels were introduced.
• E-DPDCH: E-DCH Dedicated Physical Data Channel for dedicated uplink data transmission.
During data transmission so-called Scheduling Information such as buffer status, data priority
and power headroom can be piggybacked.
• E-DPCCH: E-DCH Dedicated Physical Control Channel with the associated control data
for E-DPDCH detection and decoding. For the support of the scheduler there is a Happy Bit that
informs if the UE has sufficient resources for transmission.
• E-HICH: E-DCH HARQ Acknowledgement Indicator Channel to transmit HARQ feedback
information (ACK/NACK)
• E-RGCH: E-DCH Relative Grant Channel to grant dedicated resources (up, down, hold) to a
UE
• E-AGCH: E-DCH Absolute Grant Channel is a shared channel that allocates an absolute resource
for one or several UE.
In Figure 3 the E-DCH data and signalling flow is illustrated. Based on the rate request (Scheduling Information
or Happy Bit) the Node B may respond with a resource allocation via the absolute or a relative
grant. The UE will use the grant for data transmission and the Node B will acknowledge the received
packets.

The HARQ protocol defined for HSDPA and for E-DCH is based on an n-channel stop-and-wait protocol.
Since out of sequence delivery is a regular event for this protocol, there is a reordering function in
place to provide in-sequence delivery to higher layer protocols. Unlike in HSDPA this function is contained
in a separate sub-layer called MAC-es. MAC-es is located in the RNC since E-DCH supports soft
handover and the packets can be received by different Node Bs. It must also be noted that the
ACK/NACK reception is not reliable and there may be unwanted repetitions or even packet losses
caused by ACK/NACK misinterpretations at the sender. In that case RLC can recover the packets if configured
in acknowledged mode (AM).

BENEFITS FOR END-TO-END PERFORMANCE
Besides an increase in radio and transport network efficiency for packet based services, HSPA improves
user perception by significantly increased peak data rates and a reduced overall latency. Peak data rates
depend on the supported reference classes. Typically the operator will upgrade the network successively.
The first terminals will be a data cards enabling 1.8 Mbit/s peak data rate.

At the final state of HSPA Release 6 deployment a maximum of 14.4 Mbps will be supported in the
downlink and 5.76 Mbps in the uplink. However it should be emphasized that the peak data rates are
temporary rates at the physical layer and neglect protocol overhead at the different layer. Furthermore an
optimistically high channel code rate at the physical layer is assumed. HSPA networks are not expected to
be deployed before 2007.
In terms of end-to-end delay significant enhancements can be expected due to fast Node-B HARQ retransmission
as well as reduced transmission time interval. Fast HARQ by the Node B will save at least
two times Iub transmission delay compared to RLC ARQ retransmission. Note that the Iub is susceptible
to congestion due to missing statistical multiplexing on the low capacity last mile. HARQ uses on synchronous
ACK/NACK feedback and does not rely on infrequent event based RLC status reports. Furthermore
the interleaving delay decreases proportionally to the TTI reduction. On the other hand the
HARQ generally operates at higher block error rate and will thus have a higher number of retransmissions.
In general there is no easy calculation of the system throughput and latency reduction due to various functions
performed at the different layer. All protocol functions must be modelled realistically to take into
account the impact of encapsulation, segmentation, retransmission, reordering etc. Results will be highly
dynamic and depend on the selected scenario and parameters. Furthermore the gain for a single link may
also not necessarily turn into improvement of overall system performance. Simulations on system level
considering multiple cells and multiple users are well established as means to evaluate system performance
in today’s complex mobile communication systems. Due to the high complexity those simulations are very
time consuming and generally run offline.
Nevertheless, in our research effort Nomor Research has implemented a standard compliant UMTS system
with the enhanced features of HSPDA and E-DCH in our RealNeS platform. The Real-time Network
Simulation (RealNeS) tool with our HSPA implementation as described above allows applications to be
tested live and even provide means to perform measurements and parameter reconfigurations in real-time.

HSPA - Mobile Broadband Today

Intro
Today’s mobile communication systems have been enhanced recently to more efficiently support packet
switched services. In UMTS HSDPA and E-DCH have been specified in downlink and uplink respectively.
By now UMTS is a well-established technology with manifold networks running globally and competitive
terminals on the market. A significant shift from traditional circuit-switched, often constant bit-rate services
to IP packet switched services is expected in the near future. UMTS Release 99, based on dedicated
resource allocation per user, is not well suited for IP packet data traffic. Therefore High Speed Packet
Downlink Access (HSDPA) and Enhanced Dedicated Channel (E-DCH) have been introduced as new
features of UMTS for Downlink and Uplink in UMTS Release 5 and Release 6, respectively. This technology
called High Speed Packet Access (HSPA) claims significant enhancements in end-to-end service provisioning
for IP based services. This introduces these future technology enhancements and assesses the
potential gains for future applications and in term user perception.
In addition to the paradigm change from using dedicated resources to making use of shared radio resources,
the main technology changes introduced are:
• Fast Node B scheduling with adaptive coding and modulation (only downlink) to exploit the varying
radio channel and interference variations and accommodate bursty IP traffic,
• Node B based Hybrid ARQ to reduce retransmission round trip times and add robustness to the
system by allowing soft combining of retransmissions,
• Reduced transmission time interval (TTI) for latency reduction and to support fast scheduler decisions
and quick HARQ retransmissions.
These added functionalities have been specified in several new MAC sub-layers and modifications of the
physical layer as is depicted


In general retransmissions are now performed directly between Node B and the User equipment (UE).
This reduces latency and saves resources on the Iub interface. The distributed scheduling performed by
RNC and Node B requires an additional scheduling buffer in the Node B as well as having an additional
flow control on the Iub interface. Furthermore the Node B needs to be made aware of certain QoS parameter
to ensure that the data transmission complies with the traffic requirements. Nevertheless HSDPA
and HSUPA can be implemented in the standard 5 MHz carrier of UMTS networks and can co-exist with
the existing 3GPP Release 99 networks. In the following sections the principles of HSDPA and E-DCH
are explained in more detail.

HIGH SPEED DOWNLINK PACKET ACCESS

In downlink a new entity called MAC-hs contains the new HSDPA functionality as seen in Figure 1. Instead
of a fixed code allocation with fast power control, the code and power resource is now shared
amongst all active HSDPA users. For this purpose a new transport channel, the High Speed Downlink
Shared Channel (HS-DSCH), has been defined that supports adaptive coding and modulation, whereby
every 2ms the transmission format can change dynamically.
In good radio channel condition 16QAM modulation can be used instead of QPSK and the rate 1/3 turbo
code may be punctured down to enable higher data rates. Depending on the UE capabilities up to 15
codes with a fixed spreading factor of 16 can be received if all codes are allocated to a single UE. Since
power control is replaced by rate control with adaptive coding and modulation the maximum data rate as
received by the user directly depends on the channel and interference conditions as well as the user position
in the cell.
The Node B scheduler must take care that fairness is maintained. The dynamic resource allocation by the
scheduler (per 2ms TTI) is signalled to the users on a new downlink control channel called High Speed
Signalling Control Channel (HS-SCCH). The following information is carried on the HS-SCCH:
• UE Identity (UE ID) via a UE specific CRC which allows addressing specific UEs on the shared
control channel.
• Transport Format and Resource Indicator (TFRI) which identifies the scheduled resource and its
transmission format.
• Hybrid-ARQ-related information to identify redundancy versions for the combining process.
Each user can monitor up to 4 HS-SCCHs. For the support of channel based scheduling and HARQ the
following feedback signalling is transmitted on the High Speed Dedicated Physical Control Channel
(HS-DPCCH) in the uplink:
• Channel Quality Information (CQI) to inform the scheduler about the instantaneous channel
condition.
• HARQ ACK/NACK information to let the sender know the outcome of the decoding process
and to request retransmissions.
Figure 2 depicts the data and signalling flow during HSDPA transmission. Based on the UE channel quality
report the Node B scheduler sends data on the shared downlink channel to the user. The UE will then
reply with an ACK or NACK message based on the outcome of the decoding. Note that the standard
does not specify scheduling and resource allocation which leaves significant freedom to Node-B implementations

Resource ReSerVation Protocol - RSVP

The RSVP protocol is part of a larger effort to enhance the current Internet architecture with support for Quality of Service flows. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path.

A host uses RSVP to request a specific Quality of Service (QoS) from the network, on behalf of an application data stream.


RSVP carries the request through the network, visiting each node the network uses to carry the stream. At each node, RSVP attempts to make a resource reservation for the stream.

To make a resource reservation at a node, the RSVP daemon communicates with two local decision modules, admission control

and policy control. Admission control determines whether the node has sufficient available resources to supply the requested

QoS. Policy control determines whether the user has administrative permission to make the reservation. If either check fails,

the RSVP program returns an error notification to the application process that originated the request. If both checks

succeed, the RSVP daemon sets parameters in a packet classifier and packet scheduler to obtain the desired QoS. The packet

classifier determines the QoS class for each packet and the scheduler orders packet transmission to achieve the promised QoS

for each stream.

A primary feature of RSVP is its scalability. RSVP scales to very large multicast groups because it uses receiver-oriented

reservation requests that merge as they progress up the multicast tree. The reservation for a single receiver does not need

to travel to the source of a multicast tree; rather it travels only until it reaches a reserved branch of the tree. While the

RSVP protocol is designed specifically for multicast applications, it may also make unicast reservations.

RSVP is also designed to utilize the robustness of current Internet routing algorithms. RSVP does not perform its own

routing; instead it uses underlying routing protocols to determine where it should carry reservation requests. As routing

changes paths to adapt to topology changes, RSVP adapts its reservation to the new paths wherever reservations are in place.

This modularity does not rule out RSVP from using other routing services. Current research within the RSVP project is

focusing on designing RSVP to use routing services that provide alternate paths and fixed paths.

RSVP runs over IP, both IPv4 and IPv6. Among RSVP's other features, it provides opaque transport of traffic control and

policy control messages, and provides transparent operation through non-supporting regions.

Architecture Technology - World Largest Resort

Biocybernetics

Biocybernetics is the application of cybernetics to the biological science, comprised of biological disciplines that benefit from the application of cybernetics: neurology, multicellular systems and others. Biocybernetics plays a major role in systems biology, seeking to integrate different levels of information to understand how biological systems function.

RESEARCH IN THE BIOCYBERNETICS LABORATORY these days is somewhat eclectic, but - as alway interdisciplinary. Our work typically involves integration of theory with real laboratory data, using biomodeling, computational and biosystems approaches. Our current problem domains are physiological systems, disease processes, pharmacology, and some post-genomic bioinformatics. The pedagogy of the lab involves development and exploitation of the synergistic and methodologic interface between structural and computational biomodeling with laboratory data, or computational systems biology, with a focus on integrated approaches for solving complex biosystem problems from sparse biodata (e.g. in physiology, medicine and pharmacology), as well as voluminous biodata (e.g. from genomic libraries and DNA array data).

NEUROENDOCRINE PHYSIOLOGY RESEARCH
Our primary neuroendocrine research project involves experimental studies of thyroid hormone regulation and metabolism.Our overall long-term goal is enhancement of understanding of the hierarchical mechanisms of control of thyroid hormone (TH) production, organ distribution metabolism and excretion in mammals and fishes. Our approach is quantitative and integrative, with emphasis on both whole-organism and local organ TH regulation in health and disease states (integrated regulation of sources and sinks). Over the last 30 years, our contributions to the literature of TH metabolism and physiology have been realized using an integrated multidisciplinary investigative approach. Physiology and biochemistry laboratory methodologies have been supplemented with two distinct and highly sophisticated biomodeling and experiment design approaches pioneered in our laboratory. Both treat in vivo derived multiorgan-whole-body data, one collected from steady state tracer kinetic experiments using multisite hormone constant infusion inputs, the other from multisite hormone pulse-dose transient response kinetic experiments. We are also currently embarking on a new modality, using a new technology, MicroPET, for whole-body dynamic functional imaging, for enhancing our in vivo TH kinetic analysis approach.

We continue to emphasize three focus areas, in health versus disease states: (1) the arterio-enterohepatic system, particularly the role of intestinal components and processes in overall TH regulation (2) whole-body production of the hormone triiodothyronine (T3) from thyroxine (T4) in nonendocrine organs and from the thyroid; and (3) local organ T3 production rates, which have not been fully quantified in any organ, in any species, a problem we have nearly resolved in our most recent work.

We are also exploring alternative mechanisms including a possible "chaos" explanation for the well-established pulsatile nature of secretion of hormones from the pituitary gland. These studies utilize techniques of computational biology and nonlinear biomodeling, some developed by us, and others by collaborators at MIT, applied to human pituitary data supplied by collaborators at the University of Oregon.

SIP Session Initiation Protocol - I

The next evolutionary step after VoIP, networks, and IP Telephony, “SIP will bring Internet telephony to users’ desktops.” SIP represents the capability to reach someone regardless of location or device. Just as email can find you once you are logged in, SIP can do the same. SIP signals multiple devices until it finds you, or respects the fact that you do not want to be found. SIP is a signaling protocol. Its job is to broker communications between two devices, and once that communication is set up, SIP backs out. SIP has many of the characteristics of HTTP. It looks and acts like a URL. SIP addresses may look like an email address or even a telephone number. In fact, your email address is one way for SIP to find you. Some Example

sip:friends@latest-tech-fc.com
sip:+8185551234@gateway.com
tel:+8185551234

SIP resides at the application layer of the network and establishes, modifies, and terminates multimedia sessions between intelligent devices. This is an important concept in the world of convergence. Data networks have traditionally been unintelligent, but with very smart endpoints and devices. Telephone networks are inherently very smart, but with unintelligent endpoints (telephones).
SIP extends the intelligence of a data network out to the end user at the edge, while allowing the lesser intelligent core to forward communications requests without much effort. This makes the data network run more efficiently and effectively by putting intelligence where it is needed most. SIP also works between data and traditional telephony networks. It can broker a call between a manager’s analog home phone and an employee’s SIP enabled soft phone. If the employee is on a telephone call, it alerts the manager to another way of contacting the employee, such as sending an instant message using voice, perhaps via VxML, which is then converted to a simple text message and sent as an instant message to the employee’s PC. All the manager has to remember is the employee’s phone number.
SIP uses straightforward messages to set up, modify and terminate calls:

Invite – just like it sounds
Ack – call acceptance
Cancel – terminate search
Register – location of user (very important to the concept of presence)
Bye – ends session

SIP also easily integrates with other protocols such as the Simple Mail Transport Protocol (SMTP) as well as working with Domain Name Servers (DNS) and the Lightweight Directory Access Protocol (LDAP). SIP can handle connectionless requests using the User Datagram Protocol (UDP), which is used for voice, or connection oriented requests using the Transmission Control Protocol (TCP), which would manage a chat session. All these protocols form a communications fabric that makes it easier to locate someone, regardless of how they spell their name or what telephone number they are using. According to Frances Carincross, an industry visionary, the corporate communications network, along with the Internet, will be the “connective tissue” of an enterprise. This corporate connective tissue enables workers that are at home, in the office, or on the road to stay in touch with each other as well as customers and suppliers.

SIP Session Initiation Protocol – II

How Does it Work?
SIP provides connectivity and access. It enables communications between two SIP devices on a peer-topeer basis, and acts as a client server by allowing SIP end users, called user agents (UA) to act as clients when initiating a request, or as servers when responding to a request. This could mean an attempt to call a SIP device results in a redirection to another device. The SIP infrastructure can have SIP servers to act as proxies, gateways, registrars and redirectors to bridge into multiple devices or other environments such as linking to the public switched telephone network (PSTN) or a corporate PBX. On a peer-to-peer basis, SIP makes an invitation, which is either acknowledged or cancelled. Once the set up is complete, the Real Time Protocol (RTP) takes over to provide the actual communications. When the call is completed, the user hangs up and the SIP “Bye” message is sent out to end the session. A diagram of a simple SIP peer-to-peer call follows.

Session Initiation Protocol – SIP



Calling into a non-SIP environment requires registering to be accessible on more than one device, or for changed locations. In this case, a SIP proxy server provides services such as redirecting a call to where you have moved, launching parallel requests (forking) to more than one device or connecting into a non-SIP device such as an analog or digital PBX telephone (SIP gateway). SIP proxy servers also track users by dynamically updating changes and noting when the user is on line. This is the concept of “presence” and it enables a user to be found regardless of physical location. The primary function of SIP is to set up a connection. How communications take place depends on the device being used, the user’s status, and location in the network (presence) and the preferences listed when the user registered. For example, the manager might be on a conference call at his/her desk. If the second line rings and the manager puts the conference call on hold to speak with a client, the other participants have to tolerate music on hold until the conference operator can mute the manager’s port. Instead of disrupting a conference call the manger’s profile would state that if a call comes in from this particular client, identified by using caller ID, the caller has the option of engaging the manager in a chat session. An instant message on the manager’s PC screen might appear saying a client is trying to reach the manager (an “invite”) and he/she could accept (an ACK). The client could receive a message that says the manager is available to chat and see on his/her PC that a chat session has been set up. All of this depends on the manager’s network, devices, and desktop capabilities.
“There is already rapid growth in the number of novel and useful functions in new SIP-based systems,” said Jay Batson, founder and Chairman of Pingtel Corp., a pioneer and leader in SIP phones and technology. “Emerging SIP products are highly flexible and customizable, and are also rigorously tested for multi-vendor interoperability. This combination enables customers to find and deploy products that enhance their businesses much more simply and easily than with traditional voice systems.” SIP is an evolving standard that is slowly gaining in acceptance and use in the telecommunications industry. The number of popular PBX features it supports is also growing. The cost of SIP phones, although currently higher than digital or IP phones, will decrease as demand increases and soft phones offer more cost-effective ways to realize the benefits of SIP in locations where their use is practical (e.g., call centers). Only recently have SIP telephones begun to reach price points similar to today’s digital PBX phones.

Security, as with any IP-based device or service, is an issue, although there are security measures that can be taken such as embedding a firewall and NAT within the SIP proxy (Windows XP does this) or using stand-alone gateways. Telecommunications service providers must still address the issue of mapping PSTN numbers and SIP addresses. Recently, the Department of Commerce said it would support the electronic numbering system, known as ENUM to allow consumers to specify a single identification system for their telephone numbers, e-mail, fax numbers, cell phone numbers and instant messaging addresses. The ENUM standard, known as E.164.arpa translates telephone numbers to Internet addresses and vice versa. Enhanced 911 services are also a challenge with not just SIP, but all IP telephony devices due to the inherent mobility of IP. Since these devices essentially float in the network, ensuring E911 location information becomes a challenge. Within the SIP community several proposals have been offered ranging from installing GPS chip sets in the devices to having users simply log on to specify their location. Because a growing number of states require location information for E911 calls, this issue calls for some type of standardization across the SIP product line.

MGCP - Media Gateway Control Protocol - I

The Media Gateway Control Protocol (MGCP) implements the media gateway control
interface as a set of transactions. The transactions are composed of a command
and a mandatory response. There are nine commands:

* EndpointConfiguration

* CreateConnection

* ModifyConnection

* DeleteConnection

* NotificationRequest

* Notify

* AuditEndpoint

* AuditConnection
* RestartInProgress

The first five commands are sent by the Call Agent to a gateway. The
Notify command is sent by the gateway to the Call Agent.
The Call Agent may send either of the Audit commands to the gateway, and
the gateway may send a RestartInProgress command to the Call Agent.

General Description

All commands are composed of a Command header, optionally followed by
a session description.

All responses are composed of a Response header, optionally followed
by session description information.

Headers and session descriptions are encoded as a set of text lines,
separated by a carriage return and line feed character (or,
optionally, a single line-feed character). The session descriptions
are preceded by an empty line.

MGCP uses a transaction identifier to correlate commands and
responses. The transaction identifier is encoded as a component of
the command header and repeated as a component of the response header
Commands and responses SHALL be encoded in accordance with the
grammar, which, per RFC 2234, is case-insensitive except for the SDP
part. Similarly, implementations SHALL be capable of decoding
commands and responses that follow the grammar. Additionally, it is
RECOMMENDED that implementations tolerate additional linear white
space.

Some productions allow for use of quoted strings, which can be
necessary to avoid syntax problems. Where the quoted string form is
used, the contents will be UTF-8 encoded [20], and the actual value
provided is the unquoted string (UTF-8 encoded). Where both a quoted
and unquoted string form is allowed, either form can be used provided
it does not otherwise violate the grammar.

In the following, we provide additional detail on the format of MGCP
commands and responses.



Command Header

The command header is composed of:

* A command line, identifying the requested action or verb, the
transaction identifier, the endpoint towards which the action is
requested, and the MGCP protocol version,

* A set of zero or more parameter lines, composed of a parameter
name followed by a parameter value.

Unless otherwise noted or dictated by other referenced standards
(e.g., SDP), each component in the command header is case
insensitive. This goes for verbs as well as parameters and values,
and hence all comparisons MUST treat upper and lower case as well as
combinations of these as being equal.

Command Line

The command line is composed of:

* The name of the requested verb,

* The identification of the transaction,

* The name of the endpoint(s) that are to execute the command (in
notifications or restarts, the name of the endpoint(s) that is
issuing the command),

* The protocol version.

These four items are encoded as strings of printable ASCII
characters, separated by white spaces, i.e., the ASCII space (0x20)
or tabulation (0x09) characters. It is RECOMMENDED to use exactly
one ASCII space separator. However, MGCP entities MUST be able to
parse messages with additional white space characters.

MGCP - Media Gateway Control Protocol -II

Coding of the Requested Verb

The verbs that can be requested are encoded as four letter upper or
lower case ASCII codes (comparisons SHALL be case insensitive) as
defined in the following table:

-----------------------------
| Verb | Code |
|----------------------|------|
| EndpointConfiguration| EPCF |
| CreateConnection | CRCX |
| ModifyConnection | MDCX |
| DeleteConnection | DLCX |
| NotificationRequest | RQNT |
| Notify | NTFY |
| AuditEndpoint | AUEP |
| AuditConnection | AUCX |
| RestartInProgress | RSIP |
-----------------------------

The transaction identifier is encoded as a string of up to 9 decimal
digits. In the command line, it immediately follows the coding of
the verb.

New verbs may be defined in further versions of the protocol. It may
be necessary, for experimentation purposes, to use new verbs before
they are sanctioned in a published version of this protocol.
Experimental verbs MUST be identified by a four letter code starting
with the letter X, such as for example XPER.

Transaction Identifiers

MGCP uses a transaction identifier to correlate commands and
responses. A gateway supports two separate transaction identifier
name spaces:

* a transaction identifier name space for sending transactions, and

* a transaction identifier name space for receiving transactions.

At a minimum, transaction identifiers for commands sent to a given
gateway MUST be unique for the maximum lifetime of the transactions
within the collection of Call Agents that control that gateway.
Thus, regardless of the sending Call Agent, gateways can always
detect duplicate transactions by simply examining the transaction
identifier. The coordination of these transaction identifiers
between Call Agents is outside the scope of this specification
though.

Transaction identifiers for all commands sent from a given gateway
MUST be unique for the maximum lifetime of the transactions
regardless of which Call Agent the command is sent to. Thus, a Call
Agent can always detect a duplicate transaction from a gateway by the
combination of the domain-name of the endpoint and the transaction
identifier.

The transaction identifier is encoded as a string of up to nine
decimal digits. In the command lines, it immediately follows the
coding of the verb.

Transaction identifiers have values between 1 and 999,999,999 (both
included). Transaction identifiers SHOULD NOT use any leading
zeroes, although equality is based on numerical value, i.e., leading
zeroes are ignored. An MGCP entity MUST NOT reuse a transaction
identifier more quickly than three minutes after completion of the
previous command in which the identifier was used.

Coding of the Protocol Version

The protocol version is coded as the keyword MGCP followed by a white
space and the version number, and optionally followed by a profile
name. The version number is composed of a major version, coded by a
decimal number, a dot, and a minor version number, coded as a decimal
number. The version described in this document is version 1.0.

The profile name, if present, is represented by white-space separated
strings of visible (printable) characters extending to the end of the
line. Profile names may be defined for user communities who want to
apply restrictions or other profiling to MGCP.

In the initial messages, the version will be coded as:

MGCP 1.0

An entity that receives a command with a protocol version it does not
support, MUST respond with an error (error code 528 - incompatible
protocol version, is RECOMMENDED). Note that this applies to
unsupported profiles as well.

MGCP - Media Gateway Control Protocol -III

Capabilities

Capabilities inform the Call Agent about endpoints' capabilities when
audited. The encoding of capabilities is based on the Local
Connection Options encoding for the parameters that are common to
both, although a different parameter line code is used ("A"). In
addition, capabilities can also contain a list of supported packages,
and a list of supported modes.

The parameters used are:

A list of supported codecs.
The following parameters will apply to all codecs specified in
this list. If there is a need to specify that some parameters,
such as e.g., silence suppression, are only compatible with some
codecs, then the gateway will return several Capability
parameters; one for each set of codecs.

Packetization Period:
A range may be specified.

Bandwidth:
A range corresponding to the range for packetization periods may
be specified (assuming no silence suppression). If absent, the
values will be deduced from the codec type.

Echo Cancellation:
"on" if echo cancellation is supported, "off" otherwise. The
default is support.

Silence Suppression:
"on" if silence suppression is supported for this codec, "off"
otherwise. The default is support.

Gain Control:
"0" if gain control is not supported, all other values indicate
support for gain control. The default is support.

Type of Service:
The value "0" indicates no support for type of service, all other
values indicate support for type of service. The default is
support.

Resource Reservation Service:
The parameter indicates the reservation services that are
supported, in addition to best effort. The value "g" is encoded
when the gateway supports both the guaranteed and the controlled
load service, "cl" when only the controlled load service is
supported. The default is "best effort".

Encryption Key:
Encoding any value indicates support for encryption. Default is
no support which is implied by omitting the parameter.

Type of network:
The keyword "nt", followed by a colon and a semicolon separated
list of supported network types. This parameter is optional.

Packages:
The packages supported by the endpoint encoded as the keyword "v",
followed by a colon and a character string. If a list of values
is specified, these values will be separated by a semicolon. The
first value specified will be the default package for the
endpoint.

Modes:
The modes supported by this endpoint encoded as the keyword "m",
followed by a colon and a semicolon-separated list of supported
connection modes for this endpoint.

Lack of support for a capability can also be indicated by excluding
the parameter from the capability set.

An example capability is:

A: a:PCMU;G728, p:10-100, e:on, s:off, t:1, v:L,
m:sendonly;recvonly;sendrecv;inactive

The carriage return above is included for formatting reasons only and
is not permissible in a real implementation.

If multiple capabilities are to be returned, each will be returned as
a separate capability line.

Since Local Connection Options can be extended, the list of
capability parameters can also be extended. Individual extensions
may define how they are reported as capabilities. If no such
definition is provided, the following defaults apply:

* Package Extension attributes: The individual attributes are not
reported. Instead, the name of the package is simply reported in
the list of supported packages.

* Vendor Extension attributes: The name of the attribute is reported
without any value.

* Other Extension attributes: The name of the attribute is reported
without any value.


Coding of Event Names

Event names are composed of an optional package name, separated by a
slash (/) from the name of the actual event. The
wildcard character star ("*") can be use to refer to all packages.
The event name can optionally be followed by an at sign (@) and the
identifier of a connection (possibly using a wildcard) on which the
event should be observed. Event names are used in the
RequestedEvents, SignalRequests, ObservedEvents, DetectEvents, and
EventStates parameters.

Events and signals may be qualified by parameters defined for the
event/signal. Such parameters may be enclosed in double-quotes (in
fact, some parameters MUST be enclosed in double-quotes due to
syntactic restrictions) in which case they are UTF-8 encoded [20].

The parameter name "!" (exclamation point) is reserved for future use
for both events and signals.

Each signal has one of the following signal-types associated with it:
On/Off (OO), Time-out (TO), or Brief (BR). (These signal types are
specified in the package definitions, and are not present in the
messages.) On/Off signals can be parameterized with a "+" to turn the
signal on, or a "-" to turn the signal off. If an on/off signal is
not parameterized, the signal is turned on. Both of the following
will turn the vmwi signal (from the line package "L") on:

L/vmwi(+)
L/vmwi

In addition to "!", "+" and "-", the signal parameter "to" is
reserved as well. It can be used with Time-Out signals to override
the default time-out value for the current request. A decimal value
in milliseconds will be supplied. The individual signal and/or
package definition SHOULD indicate if this parameter is supported for
one or more TO signals in the package. If not indicated, TO signals
in package version zero are assumed to not support it, whereas TO
signals in package versions one or higher are assumed to support it.
By default, a supplied time-out value MAY be rounded to the nearest
non-zero value divisible by 1000, i.e., whole second. The individual
signal and/or package definition may define other rounding rules. All
new package and TO signal definitions are strongly encouraged to
support the "to" signal parameter.

The following example illustrates how the "to" parameter can be used
to apply a signal for 6 seconds:

L/rg(to=6000)
L/rg(to(6000))

The following are examples of event names:

-----------------------------------------------------------
| L/hu | on-hook transition, in the line package |
| F/0 | digit 0 in the MF package |
| hf | Hook-flash, assuming that the line package|
| | is the default package for the endpoint. |
| G/rt@0A3F58 | Ring back signal on connection "0A3F58" |
-----------------------------------------------------------

In addition, the range and wildcard notation of events can be used,
instead of individual names, in the RequestedEvents and DetectEvents
parameters. The event code "all" is reserved and refers to all
events or signals in a package. The star sign ("*") can be used to
denote "all connections", and the dollar sign ("$") can be used to
denote the "current" connection.

The following are examples of such notations:

---------------------------------------------------------
| M/[0-9] | Digits 0 to 9 in the MF package. |
| hf | Hook-flash, assuming that the line package|
| | is a default package for the endpoint. |
| [0-9*#A-D]| All digits and letters in the DTMF |
| | packages (default for endpoint). |
| T/all | All events in the trunk package. |
| R/qa@* | The quality alert event on all |
| | connections. |
| G/rt@$ | Ringback on current connection. |
---------------------------------------------------------

MGCP - Media Gateway Control Protocol - IV

ConnectionMode

The connection mode describes the mode of operation of the
connection. The possible values are:

--------------------------------------------------------
| Mode | Meaning |
|-------------|------------------------------------------|
| M: sendonly | The gateway should only send packets |
| M: recvonly | The gateway should only receive packets |
| M: sendrecv | The gateway should send |
| | and receive packets |
| M: confrnce | The gateway should place |
| | the connection in conference mode |
| M: inactive | The gateway should neither |
| | send nor receive packets |
| M: loopback | The gateway should place |
| | the circuit in loopback mode. |
| M: conttest | The gateway should place |
| | the circuit in test mode. |
| M: netwloop | The gateway should place |
| | the connection in network loopback mode.|
| M: netwtest | The gateway should place the connection |
| | in network continuity test mode. |
--------------------------------------------------------
Note that irrespective of the connection mode, signals applied to the
connection will still result in packets being sent

ConnectionParameters

Connection parameters are encoded as a string of type and value
pairs, where the type is either a two-letter identifier of the
parameter or an extension type, and the value a decimal integer.
Types are separated from value by an '=' sign. Parameters are
separated from each other by a comma. Connection parameter values
can contain up to nine digits. If the maximum value is reached, the
counter is no longer updated, i.e., it doesn't wrap or overflow.

The connection parameter types are specified in the following table:

-----------------------------------------------------------------
| Connection parameter| Code | Connection parameter |
| name | | value |
|---------------------|------|------------------------------------|
| Packets sent | PS | The number of packets that |
| | | were sent on the connection. |
| Octets sent | OS | The number of octets that |
| | | were sent on the connection. |
| Packets received | PR | The number of packets that |
| | | were received on the connection. |
| Octets received | OR | The number of octets that |
| | | were received on the connection. |
| Packets lost | PL | The number of packets that |
| | | were lost on the connection |
| | | as deduced from gaps in the |
| | | RTP sequence number. |
| Jitter | JI | The average inter-packet arrival |
| | | jitter, in milliseconds, |
| | | expressed as an integer number. |
| Latency | LA | Average latency, in milliseconds, |
| | | expressed as an integer number. |
-----------------------------------------------------------------

The set of connection parameters can be extended in two different
ways:

* Package Extension Parameters (preferred)

* Vendor Extension Parameters



Package Extension Connection Parameters are defined in packages which
provides the following benefits:

* A registration mechanism (IANA) for the package name.

* A separate name space for the parameters.

* A convenient grouping of the extensions.

* A simple way to determine support for them through auditing.

The package extension mechanism is the preferred extension method.

Vendor extension parameters names are composed of the string "X-"
followed by a two or more letters extension parameter name.

Call agents that receive unrecognized package or vendor connection
parameter extensions SHALL silently ignore these parameters.

An example of connection parameter encoding is:

P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48