'아는 것이 힘' 카테고리의 글 목록 (18 Page)

이동통신시장에서 흔히 사용되고 있는 용어로 Churn-in과 Churn-out이 있음.

▶️Churn-in : 전환 가입

▶️Churn-out : 전환 이탈

예를 들어 이동통신사업자가 sk, kt만 있다면 sk 가입자가 kt로 번호이동을 하였을 때 sk churn-out 한 명이 발생하였고 kt는 한 명이 churn-in된 것임

저작자표시

'아는 것이 힘 > IT세상' 카테고리의 다른 글

혼동되는 byte와 octet (0)	2016.05.02
[Mobile Network]WCDMA 구성요소 (0)	2015.02.24
[Mobile Network] GPRS vs UMTS (0)	2015.02.05
[표준단체]GSMA vs 3GPP vs IETF (0)	2015.02.05
[IFC][IMS]CNF, DNF (0)	2015.02.02

O GPRS(General Packet Radio Service)
: 무선 데이터 서비스를 제공하는 2.5G 기술로 GSM 기반임

O UMTS(Universal Mobile Telecommunications System)
: 무선 데이터 서비스를 제공하는 3G 접속망 기술로 CDMA 기반임

O GPRS & UMTS 핵심구성 요소
- SGSN(Serving GPRS support Node)
: Access와 Core망을 연결하여 GGSN으로 세션을 tunneling 함
- GGSN(Gateway GPRS Support Node)
: 단말을 PDN 및 IP망과 연결하는 구성요소

O 접속순서
: UE > RAN > SGSN > GGSN > IP N/W

O CISCO 설명 참고
GPRS and UMTS are evolutions of the global system for mobile communication (GSM) networks.
GSM is a digital cellular technology that is used worldwide, predominantly in Europe and Asia. GSM is
the world’s leading standard in digital wireless communications.
GPRS is a 2.5G mobile communications technology that enables mobile wireless service providers to
offer their mobile subscribers packet-based data services over GSM networks. Common applications of
GPRS include the following: Internet access, intranet/corporate access, instant messaging, and
mutlimedia messaging. GPRS was standardized by the European Telecommunications Standards
Institute (ETSI), but today is standardized by the Third Generation Partnership Program (3GPP).
UMTS is a 3G mobile communications technology that provides wideband code division multiple
access (CDMA) radio technology. The CDMA technology offers higher throughput, real-time services,
and end-to-end quality of service (QoS), and delivers pictures, graphics, video communications, and
other multimedia information as well as voice and data to mobile wireless subscribers. UMTS is
standardized by the 3GPP.
The GPRS/UMTS packet core comprises two major network elements:
• Gateway GPRS support node (GGSN)—a gateway that provides mobile cell phone users access to
a public data network (PDN) or specified private IP networks. The GGSN function is implemented
via Cisco IOS software on the Cisco 7200 series router or on the Cisco Multi-Processor WAN
Application Module (MWAM) installed in a Catalyst 6500 series switch or Cisco 7600 series
Internet router. Cisco IOS GGSN Release 4.0 and later provides both the 2.5G GPRS and 3G UMTS
GGSN functions.1-2
• Serving GPRS support node (SGSN)—connects the radio access network (RAN) to the
GPRS/UMTS core and tunnels user sessions to the GGSN. The SGSN sends data to and receives
data from mobile stations, and maintains information about the location of a mobile station (MS).
The SGSN communicates directly with the MS and the GGSN. SGSN support is available from
Cisco partners or other vendors.

http://www.cisco.com/c/en/us/td/docs/ios/mwgprs/configuration/guide/12_4t/mwg_12_4t_book/mwg_ggsnover.pdf

저작자표시

'아는 것이 힘 > IT세상' 카테고리의 다른 글

[Mobile Network]WCDMA 구성요소 (0)	2015.02.24
[통신][마케팅]Churn-in vs Churn-out (0)	2015.02.09
[표준단체]GSMA vs 3GPP vs IETF (0)	2015.02.05
[IFC][IMS]CNF, DNF (0)	2015.02.02
[구글 검색]키워드 검색 (0)	2015.01.30

▶️GSMA
-www.gsma.com
.통신사업자 주축
.RCS, HD Voice, VoLTE
.3pp 참조하여 서비스 요구사항 제시

▶️3GPP
- 3ggp.org
.제조사 Vendor가 주요 member임
.장비간의 I/F를 규격을 상세하게 정의함
.Release 단위로 규격을 발표함
.IETF 규격 활용

▶️IETF
.인터넷 프로토콜 표준화
.요즘 모든 장비가 IP기반으로 많이 활용됨

저작자표시

'아는 것이 힘 > IT세상' 카테고리의 다른 글

[통신][마케팅]Churn-in vs Churn-out (0)	2015.02.09
[Mobile Network] GPRS vs UMTS (0)	2015.02.05
[IFC][IMS]CNF, DNF (0)	2015.02.02
[구글 검색]키워드 검색 (0)	2015.01.30
[IMS][개발자가이드]SIP Protocol & Routing (0)	2014.12.02

[DNF]Disjuntive form: Sum of Product로써 ( + ) x( + ) 형태임
[CNF]Conjuntive form: Product of Sum으로써 ( x ) + ( x ) 형태임

iFC 항목 중 하나인 condition은 SPT 적용 조건을 CNF,DNF 중 하나로 선택함

저작자표시

'아는 것이 힘 > IT세상' 카테고리의 다른 글

[Mobile Network] GPRS vs UMTS (0)	2015.02.05
[표준단체]GSMA vs 3GPP vs IETF (0)	2015.02.05
[구글 검색]키워드 검색 (0)	2015.01.30
[IMS][개발자가이드]SIP Protocol & Routing (0)	2014.12.02
[펌]국내용 보안기술의 실상 (0)	2010.01.06

google에서 검색을 효과적으로 하는 방법

찾을 대상을 지정하고 검색 단어를 설정한다.
- intitle : 해당 제목으로 페이지 검색
- site : 지정된 도메인을 갖는 서버 검색
- inurl : 해당 단어가 url로 있는 페이지
- filetype : 해당 파일의 확장자 페이지
- intext : 해당 단어가 내용으로 있는 페이지

만약에 pdf를 찾고 싶으면 filetype:pdf 로 입력하여 검색한다.

저작자표시

'아는 것이 힘 > IT세상' 카테고리의 다른 글

[Mobile Network] GPRS vs UMTS (0)	2015.02.05
[표준단체]GSMA vs 3GPP vs IETF (0)	2015.02.05
[IFC][IMS]CNF, DNF (0)	2015.02.02
[IMS][개발자가이드]SIP Protocol & Routing (0)	2014.12.02
[펌]국내용 보안기술의 실상 (0)	2010.01.06

C 네트워크 프로그래밍 자료입니다.

출처 : http://protocol.knu.ac.kr/tech/CPL-TR-09-03-LNP.pdf

저작자표시

CSeq

:To ensure that transcation are processed in the appropriate sequence, a sequential number is assigned to each transaction with a SI

Psession. This sequential number is known as the command sequence(CSeq).

branch ID

:The branch ID identifies a transaction branch between two SIP entities. A difference between CSeq and branch ID is that the CSeq is

used end to end between two SIP entities.

If the request message contains one or more Route headers, then use the topmost Route header to determine the next hop for the messa

ge

If the request message containts no Route headers, the use the R-URI to forward the message.

'lr' URI parameter in the Router heaer stands for loose routing.

Loose routing implies the route to be followed by a request message is strictly defined through a set of Route headers("Route set")

without affecting the R-URI.

loose routing

: When a SIP Proxy receives a request message it will check the Route header present in the message. If the proxy determines from th

e Route header that this message is destined for this proxy, then the proxy removes the Route header and process the message. If the

SIP proxy determines from the Route header that this message is not destined for this proxy, then it will forward the message based

on the above-described rule(loose routing).

Via Header(transaction trail)

:Each entity that sends or forwards a request message adds a Via header to the request message, containing transport indicator(SIP/2

.0/UDP) and address of sending entity(127.0.0.1:5060) and branch value(branch=z9hG4bK-d87543, unique character string whithin the SI

P application on the host)

Response message routing is done top to bottom through the Via header set.

For a request message, routing is based on Route header and R-URI; for a response message, routing is based on Via header.

The Via header in the ACK request in reponse to a non-2XX final response will contain the same branch value as the corresponding INV

ITE request.

When a UAC cancels an INVITE transaction, it uses the same branch ID for the CANCEL transaction as was used for the INVITE transacti

on that it wants to cancel.

The subsequent transaction path is formed by a set of headers, called Record-Route headers, representing the set of proxies through

which a subsequent transaction will be routed. When a proxy want to be able to apply charging for a media session, it has to remain

in the SIP session.

It is not possible for a proxy to remove itself from a SIP signaling path once the SIP session is established.

The SIP session responder may typically include the Record-Route set in the 200 OK. If preconditions apply or early media is used, t

hen the Record-Route set will be sent in a provisional response.

To facilitate transparent and convenient addressing, the parties involved in

the establishment of a SIP session exchange their contact addresses. The user

agent that initiates the SIP session, by sending the initial INVITE

transaction, includes a Contact header in the initial INVITE request message.

The remote party of this SIP session includes a Contact header in a response

message, e.g. in the 200 OK.

UA-A uses the stored Record-Route set and contact address to set the Route

hedaer and R-URI rescpectively, in the ACK request to UA-B. UA-B uses the

stroed Record-Route set and contact address to set Route headers and R-URI in

the BYE request to UA-A.

Subsequent transaction are regular transaction and follow generic transaction

handling rules.

* Routing the request message is based on Router header and R-URI.

* A transaction trail is built up, consisting of a concaenation of branches,

reflect in a set of Via headers.

* A transaction (except ACK) has one final response and zero or more

provisional responses.

* Response message follows the same path as the request message.

* Retransmission of the request message and of the final response message may

be applide.

The sender of this request message has to apply DNS resolution in order to

determine transport protocol, IP address, and port number.

* NAPTR record query : this is used to obtain an overview of supported

services for this domain(proxy1.ims.operator-A.se) - for example, SIP over

UPD(_sip._tcp.proxy1.ims.operator-A.se).

* SRV record query : this is used to obtain host name of the SIP server

associated with the selected SIP service.

* A record query or AAA record query : This is used to obtain IP address of

the host.

Response messesge routing is esiaer than request message routing, since the

Via Headers contain the required IP service, the IP address, and the port

number.(Via: SIP/2.0/UDP 164.48.60.241;branch=z9hG4bK-d87543.

Reliability of Request Messages.

UAC starts a timer that governs the retranmission of this request message to

the next entity. This timer, referred to as 'timer A', is loaded with a

default value of 500ms. If no reponse, UAC will retransmit the request

message. The arrival of the retransmitted request message is again verified

through timer A, set to twice the default value, i.e. 2 x 500ms.

Unlike regular provisional responses, the 100 Trying is not propagated further

to the initiator of the INVITE transaction. When the UAC receive the 100

Trying, it knows that the next entity has received the INVITE. The sending of

the 100 Trying is based on the topmost Via header.

When P1 receives a retransmitted INVITE request, it determines that this

INVITE request constitutes a retransmission. The UAS state model within P1

will generate the 100 Trying response, but will not further process the

request message. The retransmitted request message is sent over the same

branch as the initial reqeust message, so carries the same branch identifier

in the Via header.

*UAC->UAS. For a non-retransmitted request message, the branch identifier

creates a new UAS instance; for a retransmitted request message, the branch

identifier indentifies the existing UAS instance.

*UAS-> UAC. The brance identifier identifies the exiting UAC instance.

The UAC ackknowledges the final response by sending an acknowledgement to the

UAS. The receipt of the final response completes the transaction for the UAC

and the receipt of the ACK completes the transaction for the UAS.

The provisional response is not sent reliably. Hence, the UAS take care not to

include information in the provisional response that is necessary for the

further handling of the transaction or for the further handling of the SIP

session.

The UAS applies a similar retransmission method for the final response as the

UAC applies for the request message. When the UAS has sent the final response,

it starts a timer(Timer G) that monitors the receipt of the ACK message for this

transaction.

For an unsuccessful final reponse, transmission and retransmission is hop by

hop.

When called party wants to receive confirmation of the successful arrival of

the provisional response at calling party, then called party may request an

acknowledgement(PRACK) from calling party.

* The PRACK transaction consist of a request message and final response(for

ACK transaction, there is no response)

* The support of the PRACK method is optional for a UA, whereas the support of

the ACK method is mandatory

* PRACK uses its own branch-ID and CSeq value

There may be multiple provisional response for a transaction; each provisional

response have a provisional acknowledgement associated with it. For this

reason, a provisional acknowledgement needs double identification; (i) the

transaction(with the sip session) it belong to; and (ii) the provisional

response with transaction it belong to.

* RSeq : Response sequence, used in a provisional response when that

provisional response is sent reliably. The RSeq header is a numerical value

identifying the response whith a transaction.

* RAck : Response Acknowledgement, used in a PRACK request message. The RAck

header is a combination of two numerical values; (i) the Response

sequence(RSeq) value for the which the PRACK is requested; and (ii) the

Command Sequence (CSeq) value of the transaction of this provisional

response. The combination of CSeq and RSeq uniquely identifies a particular

provisonal response of a particular transaction.

When called party receives a PRACK request, called party now knows that the

183 Session Progress has arrived, so can take further action like the playing

of an announcement.

Reliale response is an optional feature. UAS may apply reliable provisional

response only when both the INVITE initiator and the INVITE responder support

this feature. This support is indicated through the 'Supported' header. For

example:

INVITE sip:john.smith@company-x.se SIP/2.0

Supported : 100rel

The optina tag "100rel" is derived from "100 response class"(i.e. the class of

provisional response, excluding 100 Trying) and "rel"(reliable transmission).

The INVITE responder may indicatte in the provisional response that a reliable

provisional response is required. For example;

SIP/2.0 183 Session progress

Require: 100rel

If the INVITE request does not contain Require: 100 real, but contains

Supported: 100rel, then INVITE responder may determine per provisional

response whether reliable transmission applies.

A CANCEL transaction is a regular transaction in the sense that it consist of

a request and a final response message on a CANCEL transaction. The CANCEL

request is used only to cancel the processing of a particular INVITE

transaction. Hence, there is no need to provide any response to the CANCEL

request, other than a 200 OK, indicating that the request is received and will

be forwarded to the next hop.

When a CANCEL request arrives at an intermediate proxy, the proxy need to

match this CANCEL request with the associated INVITE transaction. This is done

by the same brach identifier for the CANCEL request as for the INVITE request.

Besides the branch identifier, the following headers in the CANCEL request

should be identical, per CANCEL hop, to the corresponding headers int the

INVITE request that is to be canceled:

* Request URI(R-URI). Using the same R-URI ensures that the CANCEL request is

routed to the same application in the UAS

* Route Header. The identical Router Header in the CANCEL request may needed

for a stateless proxy to route the CANCEL request to the same transport

address as for the INVITE request.

* Via Header. Since CANCEL is a hop-by-hop transaction, the CANCEL request

contains a single Via header only. The branch identifier will be identical to

that for the INVITE transaction for the reasons given above.

* Command Sequence. should be the same as for the INVITE transaction

When the UAS receives a CANCEL request, it generate a final response for the

INVITE transaction. The final response 487 Request Terminated is used for the

this purpose.

Since the CANCEL reqeust is send on a hop-by-hop basis, it is not possible for

the UAS to infrom the UAC about the failure of canceling the INVITE

transaction.

The cancellation of a transaction would not be possible prior to receiving the

first provisional response for the transaction.

The calling party has received a provisional response(except 100 Trying) from

the called party, a dialog is established between calling and called party.

Prior to the final response, the dialog between calling and called party is

referred to as early dialog.

The dialog identifier is composed of From tag, To tag, Call ID.

The PRACK message indicates to UA-B that UA-A has received the 183 Session

Progress and that UA-A is ready to receive (early) media.The early media may,

for example, be a personalized ringback tone generated by the terminal. The

180 Ringing provisional response gets the SIP phone to transit to the alerting

state;the subscriber may then see an indication on the display that the call

has reached the destination subscriber and that alerting has started.

The proxy forks the SIP INVITE request to the intended receiver and to a media

server. Both UA-B and media server uses establish a SIP dialog with UA-A. At

this point, both dialogs are early dialog. The media server uses the early

dialog with UA-A to transfer media to that UA-A. When UA-B answers the call,

the early dialog between UA-B and UA-A transits to the confrimed state. UA-A

will discard the early dialog with the media server and will accept only media

from UA-B.(page 208, Figure 7.41)

When early media transfer ceases(e.g. the playing of an alerting announcement

is finished), the early dialog used for the transfer of that early media is no

longer needed. Application server may send an explicit indication to the

calling party that this dialog is terminated. This indication id done through

the 199 Early Dialog Terminated response.

저작자표시

'아는 것이 힘 > IT세상' 카테고리의 다른 글

[Mobile Network] GPRS vs UMTS (0)	2015.02.05
[표준단체]GSMA vs 3GPP vs IETF (0)	2015.02.05
[IFC][IMS]CNF, DNF (0)	2015.02.02
[구글 검색]키워드 검색 (0)	2015.01.30
[펌]국내용 보안기술의 실상 (0)	2010.01.06

add2line 이용하기

addr2line 은 디버그 정보를 이용해서 파일명과 행 번호를 얻는다. 이때문에 프로그램은 미리 디버그 정보를 포함하도록 컴파일해야 한다.

gcc에서는 -g 옵션을 사용한다.

1 #include <stdio.h>

2

3 void func(void)

4 {

5 printf("func call\n");

6 }

7

8 int main(void)

9 {

10 printf(" func addr %p\n", func);

11 }

12

13

컴파일은 아래와 같이 한다.

root@boggle70-desktop:tmp# gcc -g addr2line.c

실행을 한다.

root@boggle70-desktop:tmp# ./a.out

func addr 0x8048414

먼저 헬프를 보자

root@boggle70-desktop:tmp# addr2line -help

Usage: addr2line [option(s)] [addr(s)]

Convert addresses into line number/file name pairs.

If no addresses are specified on the command line, they will be read from stdin

The options are:

@<file> Read options from <file>

-a --addresses Show addresses

-b --target=<bfdname> Set the binary file format

-e --exe=<executable> Set the input file name (default is a.out)

-i --inlines Unwind inlined functions

-j --section=<name> Read section-relative offsets instead of addresses

-p --pretty-print Make the output easier to read for humans

-s --basenames Strip directory names

-f --functions Show function names

-C --demangle[=style] Demangle function names

-h --help Display this information

-v --version Display the program's version

addr2line: supported targets: elf32-i386 a.out-i386-linux pei-i386 elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex trad-core

Report bugs to <http://www.sourceware.org/bugzilla/>

가장 간단한 예제를 살펴보자

root@boggle70-desktop:tmp# addr2line -e a.out 0x8048414

/root/tmp/addr2line.c:4

input file 과 주소를 주니 실행라인이 정확히 출력된다.

함수의 이름도 출력할수 있다.

root@boggle70-desktop:tmp# addr2line -f -e a.out 0x8048414

func

/root/tmp/addr2line.c:4

addr2line 역시 BFD 라이브러리를 이용해서 디버그 정보를 구한다.

addr2line 은 주소로부터 파일명과 행 번호를 얻을 수 있다.

출처 : http://forum.falinux.com/zbxe/index.php?document_srl=549473&mid=lecture_tip

저작자표시

'아는 것이 힘 > LINUX' 카테고리의 다른 글

[LINUX] 주기적 명령어 실행 (0)	2017.01.03
[LINUX]watch command (0)	2015.02.16
[LINUX]명령어 실행결과 정렬, 파일 내용 정렬 (0)	2015.02.15
[LINUX][Shell]Redirect & 파일 내용 지우기 (0)	2015.02.15
[grep]특정 문자열 제외하기 (0)	2014.11.17

grep 출력 결과에서 특정 문자열 제외하기

방법은 2가지이다. -v 혹은 -Ev 옵션을 사용한다.

저작자표시

'아는 것이 힘 > LINUX' 카테고리의 다른 글

[LINUX] 주기적 명령어 실행 (0)	2017.01.03
[LINUX]watch command (0)	2015.02.16
[LINUX]명령어 실행결과 정렬, 파일 내용 정렬 (0)	2015.02.15
[LINUX][Shell]Redirect & 파일 내용 지우기 (0)	2015.02.15
[Debug]add2line (0)	2014.12.02

금융결제원 - 모바일 결제, 자료>조사연구

정보통신정책연구원

대신경제연구소

금융통계정보

'아는 것이 힘 > Link' 카테고리의 다른 글

[동등한 가치] 시간에 관하여 (0)	2018.10.10
[ebook 링크] 부동산과 세금 (0)	2017.03.03
[파워포인트] 유익한 사이트 (0)	2017.01.02
[무료 도서 사이트] 구텐베르크 프로젝트 (0)	2016.11.02
[사이트] HRD100, 아이디어 발상법 (0)	2016.10.26

본문 중에서

앞으로 나가는 게 바로 생명의 본능이구나...

품위는 자기존재에 대한 당당함, 자기 일에 대한 자부심, 통제력, 타인에 대한 정직함에서 나오는 것이다....

오늘의 나와 내일의 나만을 비교하자

'아는 것이 힘 > 男兒須讀五車書' 카테고리의 다른 글

[문장 교정] 적의를 보이는 것들 (0)	2017.11.28
[마음 돋움 글귀] 나이 마흔 (0)	2017.11.22
[명심보감] 등왕각, 천복비 (0)	2017.08.04
제자백가와 사서삼경 (0)	2017.04.10
[도서]손석희가 말하는 법 (0)	2017.03.15

http://openweb.or.kr/?p=1826&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+open-web+%28Open+Web%29&utm_content=Google+Reader

'아는 것이 힘 > IT세상' 카테고리의 다른 글

[Mobile Network] GPRS vs UMTS (0)	2015.02.05
[표준단체]GSMA vs 3GPP vs IETF (0)	2015.02.05
[IFC][IMS]CNF, DNF (0)	2015.02.02
[구글 검색]키워드 검색 (0)	2015.01.30
[IMS][개발자가이드]SIP Protocol & Routing (0)	2014.12.02

간단 지식창고